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dynamic effects,  and  numerical  analysis  considerations.  The  System's  software  architec- 
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loads  and  vibrations,  acoustics,  and  aeroelastic  stability.  Solutions  are  provided  at 
levels  of  complexity  corresponding  to  the  three  aircraft  life-cycle  phases  of  preliminary 
design,  detailed  design,  and  research.  The  Support  Complex  provides  the  software 
needed  to  support  the  development,  test,  configuration  management,  and  documentation 
of  the  System. 

Capabilities  for  the  First  Level  and  Second  Level  Releases  are  presented  In  terms  of  the 
capabilities  of  each  individual  package  or  subpackage  of  software. 

The  use  of  the  System  is  presented  from  four  viewpoints:  performing  standard  analyses, 
developing  new  analysis  capabilities,  using  the  System  Interactively,  and  using  the  System 
In  a support  capacity. 
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SECTION  1 - EXECUTIVE  SUMMARY 


The  Government  and  the  helicopter  industry  need  a capability  to  accurately  predict 
helicopter  performance,  stability  and  control,  loads  and  vibrations,  acoustics, 
and  aeroelastic  stability  for  a variety  of  aircraft  configurations.  This  capability 
is  necessary  to  reduce  engineering  development  risk  for  new  aircraft,  minimize 
delays  in  deployment  of  new  aircraft,  reduce  reliability  and  maintainability  prob- 
lems of  operational  aircraft,  and  prevent  undue  restrictions  of  operational  capa- 
bilities of  Army  helicopters  due  to  unsolved  technical  problems.  Although  the 
primary  requirement  is  for  accuracy,  economy  and  reliability  are  important 
secondary  requirements. 

1. 1 OBJECTIVES  AND  LIFE  CYCLE  OF  THE  SYSTEM 

To  meet  the  analysis  needs  of  the  helicopter  community,  a program,  entitled  the 
Second-Generation  Comprehensive  Helicopter  Analysis  System  Program,  has  been 
established.  The  primary  objectives  of  the  program  are  (1)  to  develop  and  demon- 
strate a Second-Generation  Comprehensive  Helicopter  Analysis  System,  which  will 
be  a major  step  toward  satisfying  the  need  for  accurate  prediction  of  perform- 
ance, stability  and  control,  loads  and  vibrations,  acoustics,  and  aeroelastic  sta- 
bility of  helicopters  of  various  sizes  and  rotor  types,  and  (2)  to  provide  the  major 
helicopter  manufacturers  and  Government  users  an  operational  capability  using  the 
System  at  their  own  computer  facilities.  Successful  accomplishment  of  these  ob- 
jectives will  provide  an  analysis  capability  that  can  subsequently  evolve  into  a Sys- 
tem that  is  more  reliable  and  economical  as  well  as  accurate. 

To  satisfy  the  objectives  of  the  program,  a project  has  been  established  for  the 
development  of  a computer-implemented  Second-Generation  Comprehensive  Heli- 
copter Analysis  System,  hereinafter  referred  to  as  the  System.  This  System  will 
provide  a unified  treatment  of  performance,  stability  and  control,  loads  and  vibra- 
tions, acoustics,  and  aeroelastic  stability  and  will  be  applicable  to  all  stages  in 
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the  research,  development,  Improvement,  and  employment  of  helicopters.  Key 
concepts  for  this  project  include:  systematic  development,  thorough  documenta- 
tion, exhaustive  validation  by  comparison  with  test  data,  use  of  modern  computer 
hardware  and  advanced  software  techniques,  data  management,  configuration  man- 
agement, varying  levels  of  complexity  in  the  analysis  techniques  and  representa- 
tion of  helicopter  components,  computer  program  modularity,  user  aids  including 
diagnostics  and  graphics,  standardized  engineering  notation,  engineer  readable 
program  coding,  development  keyed  to  Government  and  industry  users,  and 
coupled  aerodynamic  and  dynamic  analysis. 

The  Second-Generation  Comprehensive  Helicopter  Analysis  System  effort  will  con- 
sist of  six  phases:  planning,  predesign,  development,  validation,  maintenance, 
and  user  applications.  Each  of  the  phases  is  described  in  the  sections  below. 

1. 1. 1 Planning  Phase 


The  specific  needs  for  the  System  have  been  defined  and  an  approach  to  be  taken 
throughout  development  has  been  tentatively  established.  The  initial  activity  of 
the  System  development  effort  was  to  define  the  approach  to  be  taken  throughout  the 
development  of  the  System.  The  GovernmentAndustry  Working  Group  (GIWG)  was 
established  and  participated  in  an  advisory  capacity  to  -formulate  the  overall  ap- 
proach to  be  taken.  An  Initial  Type  A System  Specification  was  written  with  the 
advice  of  the  GIWG  detailing  the  functional  capabilities  that  the  System  should 
possess.  Each  of  the  six  helicopter  companies  represented  on  the  GIWG  also  pro- 
vided the  Army  with  comments  on  the  technical  approach. 

1.1.2  Predesign  Phase 


This  final  report  documents  the  work  accomplished  by  Computer  Sciences  Corpora- 
tion (CSC)  and  its  subcontractor.  Bell  Helicopter  Textron  (BHT),  during  the  Pre- 
design Phase.  The  CSC/BHT  team  was  one  of  three  teams  selected  to  Improve  the 
Initial  Type  A System  Specification;  define  the  feasible  First  Level  Release,  Sec- 
ond Level  Release,  and  Long  Range  System  capabilities;  provide  a top-level  design 


for  the  System;  define  the  Computer  Program  Configuration  Items  (CPCIs)  that 
compose  the  System;  produce  a set  of  Type  B5  Development  Specifications;  and 
produce  a Baseline  Development  Plan.  The  Government  project  team  has  been  ad- 
vised by  the  GIWG  to  enhance  user  orientation  and  by  a Technical  Advisory  Group 
(TAG)  to  enhance  the  technical  approach.  The  Government  will  review  results  of 
this  phase,  prepare  a revised  Type  A System  Specification,  and  formulate  tentative 
requirements  for  experimental  data  to  determine  CPCI  and  System  accuracy. 

1.1.3  Development  Phase 

During  this  phase,  the  First  Level  Release  and  Second  Level  Release  capabilities 
will  be  developed  In  accordance  with  the  Type  A System  Specification  defined  In 
the  Predesign  Phase  and  In  general  accordance  with  AMCP  70-4,  Research  and 
Development  Software  Acquisition  - A Guide  for  the  Material  Developer.  The 
First  Level  Release  of  the  System  will  be  developed  using  state-of-the-art  rotary- 
wing technology  and  software  techniques  as  extensively  as  possible  without  undue 
sacrifice  In  the  potential  of  the  Second  Level  Release  and  Long  Range  System  capa- 
bilities. The  Second  Level  Release  of  the  System  will  be  developed  using  more 
advanced  rotary-wing  technology  and  software  techniques  than  used  for  the  First 
Level  Release.  It  will  Incorporate  corrections  for  errors  and  deficiencies  which 
will  have  been  Identified  after  the  First  Level  Release,  as  well  as  additional  func- 
tional capabilities  not  developed  in  the  First  Level  Release. 

The  Development  Phase  contractor,  expected  to  be  one  of  the  Predesign  Phase 
contractors,  will  be  responsible  for 

• Designing  the  System 

• Identifying  CPCIs 

• Preparing  a Type  B5  Development  Specification  for  each  CPCI,  for 
both  First  Level  Release  and  Second  Level  Release  capabilities 


• Recommending  those  CPCIs  to  be  developed  by  the  Development  Phase 
Contractor,  those  by  subcontractors,  and  those  to  be  Government- 
furnished  based  on  the  premises  that  few,  if  any.  First  Level  Release 
CPCIs  will  be  Government-furnished  and  few,  if  any,  Second  Level 
Release  CPCIs  will  be  developed  by  subcontractors 

• Developing  those  CPCIs  approved  by  the  Contracting  Officer 

• Determining  that  each  CPCI  meets  the  requirements  and  quality  assur- 
ance provisions  of  its  Type  B5  Development  Specification 

• Integrating  all  CPCIs  into  the  System 

• Conducting  a functional  demonstration  of  the  System  to  demonstrate  to 
Government  and  industry  that  the  System  meets  the  requirements  and 
quality  assurance  provisions  of  the  Type  A System  Specification 

• Defining  a unified  documentation  approach  and  editing  documentation 
for  each  CPCI  to  promote  uniformly  high  standards 

• Implementing  a configuration  management  plan 

• Providing  training  and  maintenance  support  to  Government  and  indus- 
try users  during  the  initial  portion  of  the  Validation  Phase 

The  GIWG  and  the  TAG  will  continue  to  advise  the  Government  project  team  during 
the  Development  Phase. 

The  Government  will  monitor  the  development  of  the  System  in  detail  down  to  the 
level  of  a single  line  of  code  or  engineering  equation.  The  Government  will  ap- 
prove the  Type  B5  Development  Specifications  produced  by  the  Development  Phase 
Contractor  for  each  CPCI.  The  Government  will,  in  addition,  exercise  selection 
approval  of  subcontractors  for  CPCI  development.  The  Government  will  prepare 
to  assume  full  responsibility  for  the  System  during  the  Maintenance  Phase.  The 
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Government  will  finalize  requirements  for,  and  sponsor  acquisition  of,  experi- 
mental data  necessary  to  determine  CPCI  and  System  accuracy. 

1.1.4  Validation  Phase 

The  objectives  of  the  Validation  Phase  are  to  establish  within  the  Government/ 
industry  user  community  an  operational  capability  with  the  System,  contribute  to 
the  validation  of  the  accuracy  and  operating  cost  of  the  System,  and  provide  inputs 
from  the  user  community  to  the  Development  Phase  Contractor  and  the  Government 
project  team  to  maximize  user  orientation  of  the  System  during  the  Development 
and  Maintenance  Phases. 

Helicopter  manufacturers  under  contract  to  the  Government  will  validate  the  appli- 
cability of  the  System  to  their  helicopter  types  through  correlation  with  experi- 
mental data;  these  contracts  will  be  separate  from  the  Development  Phase 
contract.  The  helicopter  manufacturers,  along  with  Government  users,  will 

• Achieve  an  operational  capability  with  the  System 

• Apply  the  System  to  current  rotary-wing  research  and  development 
efforts,  in  parallel  with  other  methods  of  analysis,  to  evaluate  the 
effectiveness  of  the  System 

• Identify  minor  errors  and  deficiencies,  determine  corrective  meas- 
ures, and  recommend  their  implementation 

• Recommend  System  enhancements  to  the  Government  project  team 

1.1.5  Maintenance  Phase 

The  Maintenance  Phase  will  be  a continuous  activity  consisting  of  System  correc- 
tion, modification,  and  development  in  response  to  errors  and  deficiencies  identi- 
fied by  the  user  community.  Further  advancements  in  the  state-of-the-art  in 
rotary- wing  analysis  and  computer  technology  will  also  be  incorporated.  The 
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responsibility  for  maintenance  will  be  assumed  by  the  Applied  Technology  Labora- 
tory, which  will  serve  as  the  focal  point  for  dissemination  of  documentation  and 
advice  on  operational  problems  encountered  using  the  System. 

1.1.6  User  Applications  Phase 

At  the  beginning  of  this  phase,  the  Govemment/industry  user  community  will  have 
attained  a mature  operational  capability  with  the  System.  With  their  own  funds, 
users  will  utilize  the  System  capabilities  for  their  own  analysis  needs.  They  will 
continue  to  provide  the  Government  with  input  to  the  maintenance  activity  so  that 
the  System  will  continue  to  meet  their  needs. 

1. 2 prmdesign  PHASE  OBJECTIVES  AND  RESULTS 

The  objectives  of  the  Predesign  Phase  were  to  improve  the  Initial  Type  A System 
Specification;  define  the  feasible  First  Level  Release,  Second  Level  Release,  and 
Long  Range  System  capabilities;  produce  a preliminary  System  design;  define 
Computer  Program  Configuration  Items  (CPCIs)  which  make  up  the  System;  pro- 
duce an  associated  set  of  Type  B5  Development  Specifications;  and  produce  a Base- 
line Development  Plan.  The  results  of  the  contractual  efforts  are  documented  in 
detail  in  the  Contract  Data  Items  (deliverables)  of  the  contract  and  are  summarized 
in  this  report.  The  paragraphs  below  correspond  to  each  objective  of  the  Prede- 
sign Phase  and  present  the  principal  results  associated  with  meeting  the  objective. 

1.2.1  Improvement  of  the  Initial  Type  A System  Specification 

A primary  objective  of  the  contract  was  to  improve  the  Initial  Type  A System  Spe- 
cification with  special  emphasis  on  the  20  critical  issues  identified  in  the  contract. 
Principal  recommended  improvements  to  the  Initial  Type  A System  Specification 
are  as  follows: 

• Add  the  major  functional  capability  of  accuracy  assessment  to  provide 
an  objective  measure  of  System  accuracy 
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• 

Make  transportability  an  explicit  requirement  of  the  System  so  that 

both  industry  and  Government  users  will  have  immediate  access  to 

the  System 
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• 

Specify  ANSI  FORTRAN  as  the  implementation  language  to  facilitate 

System  transportability  and  acceptance 

F 

» 

• 

Clarify  and  extend  the  restart  capability  to  ensure  cost  savings  in  day- 

to-day  operations  for  large  problems 

• 

Provide  an  interactive  tutorial  capability  to  enhance  user  acceptance  of 

the  System 

• 

Specify  detailed  programming  standards  to  increase  System  reliability 

and  to  decrease  documentation  and  maintenance  costs 

• 

Specify  that  the  System  design  take  into  account  virtual  memory  proc- 
essing, hardware  vector  processing,  parallel  processing,  and  cache 

memory  hardware  characteristics 

1 

• 

Replace  the  original  Section  4,  Quality  Assurance  Provisions,  with  a 

more  comprehensive  one  to  ensure  that  the  System  is  adequately  tested 

1 

1 r 

• 

Provide  an  extensive  list  of  Particular  Functional  Capabilities  including 

memory,  execution-time,  and  cost  estimates 

• 

• 

Specify  that  the  computers  for  both  the  First  Level  Release  and  the 

Second  Level  Release  be  IBM  S/370s  and  S/360s  and  CDC  6600s  and 

CYBERs  to  ensure  that  both  Industry  and  Government  users  of  the 

System  will  use  the  System  at  their  facility 

•L 

* 

i 
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1.2.2  S 

ystem  Capabilities 

System  capabilities  were  allocated  to  the  First  Level  Release  and  the  Second  Level 

Release  based  on  (1)  the  prescribed  budget  Is  20  professional  man-years  per  year 
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for  4 years;  (2)  the  schedule  for  completion  of  the  First  Level  Release  is  2 years 
after  Development  Phase  contract  award  and  the  schedule  for  completion  of  the 
Second  Level  Release  is  4 years  after  Development  Phase  contract  award;  (3)  rel- 
atively high  priorities  are  assigned  to  System  capabilities  for  problem  analyses 
for  the  detailed  design  and  preliminary  design  aircraft  life  cycle  phases  compared 
to  priorities  for  the  research  aircraft  life  cycle  phase,  and  (4)  the  man-month  es- 
timates for  CPCI  development  that  were  made  during  the  Predesign  Phase. 

% 

1. 2. 2. 1 First  Level  Release  Capability 

The  First  Level  Release  consists  of  helicopter  analysis  capabilities  for  perform- 
ance, stability  and  control,  aeroelastic  stability,  and  rotor  loads  and  vibrations 
for  the  aircraft  life  cycle  phases  of  preliminary  design  and  detailed  design.  An 
acoustics  analysis  capability  is  also  provided  for  preliminary  design. 

The  First  Level  Release  capability  in  terms  of  physical  components  is  as  follows. 

The  rotor  representations  include  semiempirical  equations,  rigid-blade  equations, 
and  dynamic  analyses  for  all  rotor  types  with  lag  dampers,  flapping  stops,  and  lag 
stops.  A general  rigid  control  system  is  represented.  The  drive  system  repre- 
sentation includes  rigid  and  static  elastic  analyses  with  an  engine  performance 
table.  The  airframe  representation  includes  a rigid  fuselage,  aerodynamic  sur- 
faces,  stores,  and  pylons,  as  well  as  a simple  landing  gear.  The  capability  for 
the  airmass  includes  steady  aerodynamic  coefficients  using  tables;  unsteady  aero- 
dynamic coefficients  using  Theodorsen/Loewy  or  Of , A , B methods;  momentum 
theory  flow  field  with  or  without  time  delay;  and  a prescribed  rotor  wake.  Pre- 
scribed motions  of  a ground  or  deck  surface  are  included  as  well. 

I . | 

Executive  software  in  a batch  mode  will  by  and  large  be  complete  for  the  First 

Level  Release.  The  only  principal  Executive  software  capability  postponed  to  the  • 

Second  Level  Release  is  the  capability  to  run  the  System  in  an  interactive  mode. 

Support  software  is  complete  by  the  First  Level  Release.  The  First  Level  Release 
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of  the  System  will  be  available  on  the  IBM  S/370  and  S/360  computers  and  on  the 
CDC  6600  series  and  CYBER  series  computers. 

1.2. 2. 2 Second  Level  Release  Capability 

In  addition  to  all  of  the  capabilities  of  the  First  Level  Release,  the  Second  Level 
Release  provides  analysis  capabilities  for  performance,  stability  and  control, 
loads  and  vibrations,  acoustics,  and  aeroelastic  capability  for  the  research  air- 
craft life  cycle  phase.  Also  included  in  the  Second  Level  Release  are  (1)  the 
acoustics  capability  for  detailed  design  and  (2)  the  loads  and  vibrations  capability 
for  the  airframe,  the  engine/drive  system,  and  the  control  system/pilot  for  pre- 
liminary design  and  detailed  design.  Another  significant  capability  provided  by 
the  Second  Level  Release  is  a capability  to  assess  the  effects  of  damage  to  or  fail- 
ure of  the  various  aircraft  components  (e.  g. , rotor  blade,  engine/drive  system 
components).  The  user  will  be  able  to  use  all  the  Second  Level  Release  analysis 
capabilities  in  an  interactive  mode  on  the  IBM  S/370  and  S/360  and  on  the 
CDC  6600  and  CYBER  series  computers. 

The  Second  Level  Release  capability,  in  terms  of  physical  components,  is  as  fol- 
lows. The  rotor  representations  include  elastic  rotor  blades,  semiempirical  cir- 
culation control  rotors,  semiempirical  reaction  drive  rotors,  pendulum  absorbers, 
control  load  reduction  devices,  and  servo  flaps.  The  control  system/pilot  repre- 
sentations include  elastic  control  systems,  dynamic  control  systems,  force  feel 

systems,  automatic  flight  control  systems,  control  feedback  from  force/motion  > 

sensors,  and  pilot  transfer  functions.  The  engine/drive  system  representations 

Include  detailed  engine  analysis  with  a governor  and  fuel  control  devices;  a rigid, 

static  elastic,  and  dynamic  gearbox;  a dynamic  driveshaft;  and  a clutch.  The 

airframe  representations  include  a static  elastic  and  dynamic  fuselage,  a static 

elastic  and  dynamic  aerodynamic  surface,  vibration  control  devices,  suspended 

cargo,  a complex  landing  gear,  dynamic  stores,  and  hoist  and  load  stabilization 
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devices.  The  airmass  representation  includes  free  rotor  wake,  cable  aerodynam- 
ics, unsteady  aerodynamic  loadings,  wind  tunnel  wall  and  blockage  effects,  and 
aerodynamic  interference  effects  between  and  among  rotors,  aerodynamic  sur- 
faces, and  bodies.  Also  included  is  an  aerodynamic  analysis  for  arbitrary  bodies 
and  nonrotating  lifting  surfaces.  Other  analysis  components  include  a dynamic 
test  stand,  an  elastic  or  plastic  deformable  ground  or  deck  surface,  and  a water 
surface. 

1. 2. 3 Design  of  the  System  * 

The  System  design  provides  the  flexibility  to  analyze  helicopter  components  (e.g. , \ 

rotor,  fuselage)  separately  or  in  combination.  Although  the  System  design  ensures 

accurate  solutions  to  large  problems,  which  characterize  the  research  aircraft 

life  cycle  phase,  the  System  design  also  provides  an  efficient  solution  to  small 

problems,  which  characterize  the  preliminary  design  aircraft  life  cycle  phase. 

The  usability  of  the  System  has  been  a prime  design  goal  throughout  the  contract. 

Engineering  users  will  use  the  System  as  an  analysis  tool  as  an  integral  part  of 
their  day-to-day  work.  Fulfilling  the  needs  of  the  engineering  user  while  at  the 
same  time  making  the  System  easy  to  use  (i.e. , not  requiring  the  engineering 
user  to  know  the  internal  design  of  the  System)  has  been  a principal  design  ob- 
jective.  In  addition,  the  needs  of  the  methods  developer,  who  will  use  the  System 
as  a foundation  to  explore  new  and  Improved  analysis  techniques  that  will  eventu- 
ally be  incorporated  in  the  System,  have  also  been  met.  A summary  of  the  Sys- 
tem design  is  presented  in  Section  1. 3.  Section  2 presents  a detailed  summary  t 

of  the  design  presented  in  the  Predesign  Phase  Type  B5  Development  Specifi- 
cations for  the  Second  Generation  Comprehensive  Helicopter  Analysis  System, 

CSC/SD-78/6083. 

1.2.4  Computer  Program  Configuration  Items 

1 * 

CSC  defined  as  Computer  Program  Configuration  Items  (CPCIs)  204  software  ele- 
ments of  the  System.  This  large  number  of  software  elements  were  designated  as 
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CPCIs  to  provide  the  visibility  necessary  for  determining  which  of  the  elements 
are  candidates  for  development  by  the  Government  and  subcontractors.  However, 

CSC  recommends  that  the  number  of  CPCIs  for  the  Development  Phase  be  greatly 
reduced  in  order  to  minimize  the  costs  associated  with  the  procurement,  docu- 
mentation,  and  configuration  management  of  CPCIs. 

1.2.5  Type  B5  Development  Specifications 

The  Type  B5  Development  Specifications  produced  during  the  Predesign  Phase 
present  a unified  treatment  of  the  mathematical  basis  of  the  System  in  which  all 
System  analyses  are  derived  from  one  master  set  of  differential  equations  in 
matrix  form.  Another  feature  of  the  Type  B5  Development  Specifications  is  an 
extensive  discussion  and  numerous  examples  of  how  the  System  is  used  by  the 
engineering  user  and  the  methods  developer.  The  software  design  of  the  System 
is  presented  in  a format  called  Hierarchy  Plus  Input  Process  Output  (HIPO)  that 
presents  the  elements  of  the  design  in  an  organized,  reader-oriented  fashion. 

Data  flow  diagrams  show  how  the  software  elements  of  the  System  are  related  to 
each  other  and,  most  important,  illustrate  the  flow  of  data  within  the  System  for 
the  five  major  technical  characteristics:  performance,  stability  and  control, 
loads  and  vibrations,  acoustics,  and  aeroeiastlc  stability..  Finally,  a functional 
description  of  each  CPCI  is  presented. 

1.2.6  Baseline  Development  Plan 

The  System  development  plan,  which  is  summarized  in  Section  5 of  this  report,  l 

consists  of  the  following:  organization  and  responsibilities,  technical  plans,  man- 
agement plans,  and  a time-phased  plan  for  Implementing  the  software  elements  of 
the  First  Level  Release  and  the  Second  Level  Release. 

1. 2. 6. 1 Organization  and  Responsibilities 

The  plan  for  organization  and  responsibilities  in  the  Development  Phase  emphasizes 
the  need  for  effective  communication  throughout  development  and  defines  in  some 
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detail  the  responsibilities  of  participating  organizations — the  Applied  Technology 
Laboratory,  the  Development  Phase  contractor,  the  integrated  team  member  sub- 
contractor, CPCI  subcontractors,  the  Government/Industry  User  Community,  the 
Government/Industry  Working  Group,  and  the  Technical  Advisory  Group. 

1.2. 6. 2 Technical  Plans 

Technical  plans  include  those  for  quality  assurance,  testing,  documentation,  pro- 
viding an  effective  software  development  computing  environment,  managing  System 
software  and  data,  installing  the  System  at  user  sites,  training,  and  maintenance. 

The  quality  assurance  plan  features  effective  techniques  to  ensure  that  users  re- 
ceive a high-quality  System:  top-down  development;  use  of  modern  software  sys- 
tem design  presentation  techniques  (e.g. , Program  Design  Language,  HIPO,  data 
flow  diagrams);  structured  walkthroughs  for  design  and  coding  review;  structured 
programming  techniques;  automated  tools  to  assess  conformance  of  source  code 
to  programming  standards;  independent  testing;  and  a separate  organizational 
element  to  ensure  that  these  techniques  are  implemented. 


Features  of  the  remaining  technical  plans  are  as  follows: 


Plan 

Highlight 

Benefit 

Testing 

Test  documentation 
plan 

Provides  sufficient  yet 
cost-effective  control  of 
testing 

Automated  test  tools 

Provides  a quantitative 
assessment  of  the  scope 
of  testing 

Documentation 

Integration  of  MIL- 
STD-490  standards  with 
those  of  DoD  Manual 

4120. 17-M 

Avoids  duplication  of 
effort,  thus  reducing  costs 

Software  Development 
Computing  Environ- 
ment 

Terminals  dedicated 
to  System  develop- 
ment 

Increases  programmer 
productivity 
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Plan 


Highlight 


Benefit 


Data  Management 


Installation  and 
Release 


Effective  library  Avoids  loss  in  productivity 

controls  in  case  of  inadvertent  de- 

struction of  tapes/disks 

System  installation  at  Enhances  user  acceptance 
each  user's  site 


Training 


Maintenance 


Programmer  training 
in  addition  to  user 
training 


Effective  communica- 
tion of  System  status 


Permits  an  installation  to 
make  local  changes  inde- 
pendent of  those  supplied 
centrally  by  the  Applied 
Technology  Laboratory 

Enhances  user  acceptance 


1.2. 6. 3 Management  and  Implementation  Plans 

The  management  plans  emphasize  the  need  for:  a System  Development  Plan  to  pro- 
vide a public  statement  of  all  management  and  technical  project  plans;  effective 
communication  among  all  organizations;  internal  as  well  as  external  review  and 
reporting  procedures;  and  configuration  management  controls. 

The  principal  characteristic  of  CSC's  time-phased  plan  for  implementing  the  soft- 
ware elements  of  the  First  Level  Release  and  the  Second  Level  Release  is  that  it 
has  been  shaped  by  the  strategy  of  builds,  a powerful,  proven  software  implemen- 
tation strategy  that  minimizes  risk.  Because  of  the  System's  size  and  complexity, 
it  should  be  developed  and  tested  incrementally.  A build,  which  is  a subset  of  the 
entire  System,  provides  a demonstrable  (i.e. , testable)  functional  capability  that 
is  a subset  of  the  total  functional  capability  of  the  System.  The  System  is  con- 
structed in  a sequence  of  builds,  where  each  build  contains  all  of  the  capability  of 
the  previous  build  in  the  sequence  plus  new  capability.  This  "build-a-llttle,  test- 
a-little" philosophy  has  several  advantages  over  the  alternative  strategy  of  devel- 
oping all  the  software  elements  required  to  produce  the  First  Level  Release 
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capability  and  then  all  the  software  elements  required  to  produce  the  Second  Level 
Release  capability.  These  advantages  are  as  follows: 

• If  there  are  any  major  interface  problems  (e.g. , between  Executive 
and  Technology  software),  they  will  be  discovered  early  enough  so 

that  corrections  can  be  made  without  affecting  the  schedule  for  com-  * 

pleting  either  the  First  Level  Release  or  the  Second  Level  Release. 

• Integration,  the  phase  in  the  development  life  cycle  where  software  in-  % 

terface  problems  historically  have  surfaced,  is  spread  more  smoothly 

over  the  entire  Development  Phase  rather  than  being  placed  near  the 
end.  Risk  is  thus  reduced. 

• A stable  and  well-defined  partial  System  is  available  for  testing  fol- 
lowing the  first  build. 

• A part  of  the  total  System  capability  is  demonstrated  to  the  Govern- 
ment and  to  System  users  early  so  that  user  experience  can  influence 
the  final  delivered  System. 

1.3  OVERVIEW  OF  THE  SYSTEM  DESIGN 

The  summary  of  the  System  design  in  the  subsections  below  is  presented  from  three 
different  points  of  view:  that  of  an  engineering  manager  (Section  1.3. 1),  that  of  an 
engineering  user  (Section  1.3.2),  and  that  of  a programmer  (Section  1.3.3).  An 
overview  of  the  data  that  the  System  will  process  is  allocated  an  entire  subsection, 

I 

Section  1.3.4.  A separate  subsection  is  used  to  demonstrate  the  importance  that 
CSC  attaches  to  a systems  view  of  data:  without  such  a systems  approach,  overall 
life  cycle  costs  can  escalate. 

Acceptance  of  the  System  as  a standard  throughout  the  helicopter  industry  requires  • 

that  the  System  possess  seven  characteristics: 

1.  Accuracy,  i.e. , the  System  must  provide  accurate  methods  to  analyze 
helicopter  configurations. 
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Usability,  i.e. , the  System  must  be  easy  to  use  by  the  engineering 
analyst. 

3.  Transportability,  i.e. , it  must  be  easy  to  move  the  System  from  one 
computer  family  to  another,  with  minimum  modifications. 

4.  Extendability,  i.e. , it  must  be  easy  to  add  new  analysis  capabilities 
and  to  modify  existing  analysis  capabilities  without  changing  software 
unrelated  to  the  capability  being  added  or  modified.  In  addition,  it 
must  be  easy  to  experiment  with  new  or  modified  capabilities. 

5.  Reliability,  i.e. , the  System  must  provide  the  engineering  analyst  with 
confidence  in  the  adequacy  of  the  analysis  upon  which  the  System  design 
is  based. 

6.  Maintainability,  i.e. , it  must  be  easy  to  isolate  and  correct  deficien- 
cies in  the  System. 

7.  Efficiency,  1.  e. , the  System  must  be  able  to  efficiently  analyze  both 
small  and  large  problems. 

The  System  characteristics  of  accuracy,  reliability,  and  usability  are  dependent 
upon  a mathematical  basis  which  inherently  provides  a foundation  for  achieving 
these  three  goals  and  upon  a design  which  recognizes  the  importance  of  these 
goals.  Section  1.3. 1 discusses  the  relationship  between  the  mathematical  basis 
of  the  system  and  the  System  characteristics  of  accuracy,  reliability,  and  usa- 
bility. 

1.3.1  An  Engineering  Manager's  Overview  of  the  System 

For  the  System  to  be  accepted  as  a standard  by  the  helicopter  analysis  community, 
it  must  be  based  on  a mathematical  approach  which  Inherently  provides  a basis  for 
an  accurate,  reliable,  and  user-oriented  analysis  capability.  CSC/BHT  has  there- 
fore selected  a design  approach  that  provides  the  analysis  capability  needed  to 
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accurately  evaluate  helicopter  designs,  the  reliability  needed  to  ensure  confidence 
in  the  analysis  performed,  and  the  ease  of  utilization  needed  to  ensure  acceptance 
by  the  individual  helicopter  engineer.  The  mathematical  foundation  of  the  System 
design  is  based  on  a unified  mathematical  approach  for  all  analysis  performed  by 
the  System  and  on  the  definition  of  a user-interface  environment  oriented  to  the 
engineer  and  the  problem  to  be  solved  rather  than  to  the  programmer  and  the  soft- 
ware solution  to  the  problem. 

1. 3. 1. 1 Summary  of  the  Unified  Mathematical  Approach  •. 

The  unified  mathematical  approach  involves  three  basic  concepts.  First,  helicopter 
analysis  and  simulation,  In  the  most  general  form,  can  be  represented  by  a sys- 
tem of  differential  equations  in  the  form  of  the  following  matrix  equation: 

[M]  {q)  +[C]{q)  +[K]{q)  ={F}  (1) 

where  (q)  , {q}  , and  [q]  are  generalized  displacement,  velocity,  and  accelera- 
tion vectors,  respectively;  CM]  , [C]  , and  [K]  are  the  mass,  damping,  and 
stiffness  matrices,  respectively,  of  the  aircraft  configuration  under  analysis 
(these  matrices  may  be  constant,  periodic,  otherwise  time  variant,  or  weak 

functions  of  the  [q]  and  [q]  vectors);  and  [F]  is  a vector  of  generalized  ’ 

forces  that  may  be  constant  but  is  more  commonly  periodic  or  otherwise  time 
variant.  In  addition,  [F]  may  be  a linear  or  nonlinear  function  of  the  [q]  and 

' ^ 

Jq]  vectors. 

All  helicopter  analysis  problems  to  be  analyzed  by  the  System  can  be  represented  ^ 

by  this  equation  or  variations  thereof.  The  determination  of  steady-state  or  trim 
conditions,  a basic  requirement  for  virtually  all  helicopter  analysis  problems,  is 
based  on  a variation  of  this  basic  equation.  The  natural  frequencies  and  mode  * 

shapes  of  the  aircraft  structure  and  its  components  are  derived  using  a variation 
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of  this  basic  equation.  For  stability  analysis,  the  calculation  of  stability  deriva- 
tives is  based  on  this  same  basic  equation.  Finally,  transient  aircraft  maneuver 
problems  are  represented  using  this  basic  equation.  The  use  of  this  single  basic 
differential  equation  is  the  first  concept  that  unifies  the  mathematical  basis  of  the 
System. 

The  second  concept  that  unifies  the  mathematical  basis  of  the  System  is  the  finite 
element  approach  for  representing  helicopter  components.  The  finite  element  ap- 
proach has  been  successfully  employed  in  structural  analysis  applications  for  many 
years.  In  recent  years,  the  feasibility,  suitability,  and  adaptability  of  this  ap- 
proach for  analyzing  helicopter-related  structures  have  been  widely  demonstrated. 
The  finite  element  approach  provides  a unified  concept  applicable  to  static  analysis, 
dynamic  analysis,  and  the  analysis  of  aerodynamic  effects. 

The  third  unifying  mathematical  concept  included  in  the  System  is  the  capability  to 
analyze  a physical  configuration  composed  of  independently  defined  components.  , 

The  finite  element  approach  is  directly  applicable  to  combining  aircraft  and  other 
components  to  form  a variety  of  configurations.  The  CSC/BHT  design  provides  a 
general  and  systematic  method  of  coupling  various  components  to  yield  complex 
structures  or  configurations.  Two  approaches  to  coupling  of  components  were 
considered:  the  substructure  analysis  approach  and  the  component  modes  ap- 
proach. The  CSC/BHT  system  design,  because  it  is  based  on  the  finite  element 
approach,  can  accommodate  either  approach  to  coupling  of  components.  However, 
the  projected  funds  available  for  the  Development  Phase  may  not  permit  both  ap- 
proaches to  be  implemented.  Because  of  the  potential  computer  cost  savings  that 
can  be  realized  if  the  component  modes  approach  is  used  for  coupling  of  compo- 
nents, the  component  modes  approach  is  included  in  the  design  for  the  First  Level 
Release  of  the  System.  In  addition,  it  is  recommended  that,  if  funding  permits, 
the  substructure  analysis  approach  to  component  coupling  be  added  to  the  Second 
Level  Release  of  the  System. 


The  finite  element  approach  is  also  applicable  to  analyzing  the  aerodynamic  flow 
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field  and  its  effect  upon  various  components  of  a helicopter  configuration.  Aero- 
dynamic models  (rather  than  structural  models)  can  be  employed  to  define  the  in- 
teraction between  the  structure  and  the  surrounding  airmass.  For  maximum 
flexibility,  the  design  permits  aerodynamic  node  points  to  differ  from  dynamic 
node  points. 

The  combination  of  a single  basic  differential  equation,  the  finite  element  ap- 
proach, and  a systematic  method  to  couple  components  results  in  a unified  mathe- 
matical basis  for  accurately  and  reliably  analyzing  helicopter  configurations. 

This  approach  also  enhances  the  usability  of  the  System  by  the  engineer  because 
it  provides  a consistent  and  unified  way  of  defining  helicopter  models,  analyzing 
helicopter  configurations,  and  assessing  the  results  of  the  analysis.  The  use  of 
specialized  analytical  formulations  was  rejected  because  such  an  approach  would 
have  a severe  impact  on  the  ease  of  using  the  System. 

1. 3. 1. 2 Summary  of  the  User's  Interface 

A major  design  goal  established  by  CSC/BHT  was  to  facilitate  the  use  of  the  Sys- 
tem by  an  engineer.  Basing  the  System  design  on  a unified  mathematical  concept 
is  the  first  step  in  accomplishing  this  goal.  To  fully  meet  this  goal,  an 
engineering-oriented  interface  is  defined  that  allows  the  engineer  to  specify  the 
problem  to  be  solved  in  terms  of  the  problem  components  rather  than  in  terms  of 
the  software  components.  This  user/problem  orientation  eliminates  the  user's 
need  to  know  the  internal  design  of  the  System;  users  can  thus  focus  their  attention 
where  it  belongs:  on  the  helicopter  rather  than  on  the  System. 

Six  of  the  key  elements  of  the  user  Interface  provided  in  the  design  are  verification 
of  input  before  performing  the  analysis;  meaningful  diagnostic  messages  that  use 
engineering  terminology  rather  than  software  terminology;  capability  to  define 
input  at  an  interactive  terminal;  capability  to  view  System  output  at  an  interactive 


terminal;  engineering-oriented  analysis  reports;  and  graphic  presentation  of 
analysis  results. 

Two  unique  approaches  included  in  the  design  eliminate  the  need  for  the  engineer 
to  understand  the  software  design  in  describing  either  the  problem  to  be  solved 
or  the  analysis  to  be  performed.  These  two  key  approaches  are  simplification  of 
the  definition  of  the  physical  configuration  and  simplification  of  the  analysis  defi- 
nition. 

• One  of  the  biggest  user-interface  problems  associated  with  finite  element  ap- 

proaches is  the  large  amount  of  data  required  to  represent  a complex  model.  To 
solve  this  problem,  the  design  provides  an  environment  in  which  the  engineer  de- 
fines the  problem  to  be  solved  in  terms  of  the  aircraft  components  comprised  in 
the  physical  configuration.  A data  base  of  aircraft  component  descriptions  will 
be  available  so  that  the  engineer  need  not  explicitly  include  a description  of  each 
component  comprised  in  the  overall  physical  configuration  to  be  analyzed.  To 
describe  the  physical  configuration  the  engineer  need  only  indicate  the  aircraft 
components  to  be  used  and  the  way  in  which  they  are  to  be  coupled.  If  desired, 
modifications  to  the  component  descriptions  as  stored  in  the  data  base  can  be 
specified  at  the  time  the  analysis  run  is  made.  If  a new  component  is  required, 
it  either  can  be  explicitly  described  in  the  analysis  run  or  can  first  be  added  to 
the  data  base  of  components.  The  data  base  of  components  eliminates  the  need 
to  include  descriptions  of  frequently  used  and  stable  components  in  each  analysis 
run,  thus  minimizing  the  amount  of  data  that  the  engineer  must  supply  for  an  anal- 
ysis. 

I 

The  definition  of  the  analysis  to  be  performed  is  another  user  problem  addressed 
by  the  design.  All  too  frequently,  automated  analysis  systems  require  that  the 

i engineer  understand  the  software  design  of  the  system  in  order  to  define  the  anal- 

ysis to  be  performed.  The  CSC/BHT  design  solves  this  problem.  In  defining  the 
analysis  to  be  performed,  the  engineer  need  only  specify  the  major  analytical 
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functions  to  be  performed  (e.g. , find  a steady-state  flight  condition,  calculate 
stability  and  control  data,  determine  acoustic  responses).  The  System  itself  then 
translates  these  analysis  specifications  into  a detailed  command  sequence  that  is 
oriented  to  the  software  structure  of  the  System.  This  approach  eliminates  the 
need  for  the  engineer  to  understand  the  software  design,  thus  allowing  the  analysis 
to  be  defined  in  terms  of  the  types  of  analysis  to  be  performed  rather  than  in  terms 
of  the  software  elements  to  be  executed.  If  desired,  engineering  users  and  de- 
velopers of  new  algorithms  and  new  capabilities  to  be  incorporated  in  the  System 
(these  latter  users  are  called  methods  developers)  may  construct  their  own  de- 
tailed command  sequences  or  modify  existing  ones.  The  detailed  command  se- 
quences are  retained  on  a data  base  so  that  new  major  functions  or  modifications 
to  existing  functions  can  be  permanently  defined  for  subsequent  use  by  the  engi- 
neering community  at  an  installation.  The  definition  of  a new  command  sequence 
or  a modification  to  an  existing  command  sequence  does  not  require  any  software 
modifications  unless  interfaces  among  software  elements  are  changed. 

1.3.2  An  Engineering  User's  Overview  of  the  System 

The  Second  Generation  Comprehensive  Helicopter  Analysis  System  performs  the 
previously  described  helicopter  analysis  in  three  phases:  input,  processing,  and 
output.  A diagram  of  the  System  data  flow  is  provided  in  Figure  1. 

1. 3. 2. 1 Input  Phase 

In  the  input  phase,  the  System  reads  a user  input  file,  which  may  be  either  a card 
deck,  a card-image  file,  or  a file  prepared  from  an  interactive  terminal.  Infor- 
mation in  the  user  input  file  is  the  basis  for  locating  in  the  Master  Data  Base  the 
descriptions  of  the  aircraft  configuration  to  be  analyzed  and  the  conditions  for  the 
analysis  and  placing  those  descriptions  in  the  Run  Data  Base.  Information  in  the 
user  input  file  is  also  the  basis  for  selecting,  from  the  Master  Command  File, 
predefined  sequences  of  System  Commands  which  identify  the  sequence  of  opera- 
tions required  to  perform  the  analysis,  and  placing  the  complete  sequence  in  the 
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Figure  1.  'Engineering  User's  View  of  the  System 


Sequence  Control  Table.  The  data  in  the  Master  Data  Base  and  the  sequences  of 
operations  (System  Commands)  in  the  Master  Command  File  are  stored  by  data 
base  maintenance  personnel.  A restart  file  may  be  used  to  begin  processing  from 
an  intermediate  point  in  an  earlier  analysis  run  without  the  necessity  of  repeating 
the  processing  required  to  reach  the  restart  point.  During  the  input  phase,  re- 
ports showing  all  user  inputs  in  a variety  of  formats  are  available.  If  an  input 
error  exists,  the  System  produces  diagnostic  messages  in  clear,  meaningful,  en- 
gineering terms.  At  user  option,  the  System  estimates  the  cost  of  performing 
the  analysis  run  instead  of  proceeding  to  the  processing  phase. 

1.3. 2. 2 Processing  Phase 

In  the  processing  phase,  the  System  uses  the  information  in  the  Sequence  Control 
Table,  which  is  the  sequence  of  System  Commands  required  to  perform  the 
analysis,  to  control  the  sequence  of  helicopter  analysis  operations.  The  System 
Commands  chosen  depend  on  the  problem  to  be  solved  and  the  analysis  to  be  per- 
formed. The  data  placed  in  the  Run  Data  Base  during  the  input  phase  are  input  to 
the  processing  phase.  The  Run  Data  Base  also  contains  intermediate  and  final  re- 
sults produced  by  the  System  during  its  processing  phase  operation  either  for  use 
later  in  the  processing  phase  or  for  subsequent  output.  Output  includes  printed 
and  plotted  results  and  files  that  can  be  processed  at  the  completion  of  the  analysis 
run  (post-processing)  and  input  to  other  software  systems.  During  the  processing 
phase,  in  addition  to  results  stored  in  the  Run  Data  Base,  the  System  produces 
diagnostic  messages  to  report  implicit  errors  in  user  input  (explicit  errors  are 
diagnosed  in  the  input  phase),  diagnostic  messages  to  report  Internal  System 
problems,  a restart  file  on  user  option,  and  prints  or  plots  of  intermediate  results. 

1.3. 2. 3 Output  Phase 

In  the  output  phase,  the  System  outputs  the  final  results  of  the  analysis.  The  par- 
ticular quantities  to  be  output  may  be  explicitly  specified  via  user  input.  In  the 
absence  of  such  explicit  specification,  predefined  printed  output  is  produced.  The 
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results  to  be  output  are  retrieved  from  the  Run  Data  Base,  where  they  were  stored 
during  the  processing  phase.  The  user  may  also  specify  quantities  output  to  files 
intended  as  input  to  programs  external  to  the  System  (i.e. , the  External  Models 
Functional  Capability). 

1.3.3  A Programmer's  Overview  of  the  System 

The  hierarchy  diagram  in  Figure  2 provides  a System  overview  to  programmers 
interested  in  the  architecture  of  the  System.  The  figure  shows  the  division  of  the 
System  into  the  Operational  Complex  and  the  Support  Complex  and  the  further  divi- 
sion of  the  Operational  Complex  Into  two  types  of  subsystems,  Technology  and 
Executive.  The  Operational  Complex  is  that  part  of  the  System  that  is  used  by  the 
engineer  to  obtain  predictions  of  rotary-wing  aircraft  performance,  stability  and 
control,  loads  and  vibrations,  acoustics,  and  aeroelastic  stability.  The  Support 
Complex  is  that  part  of  the  System  that  is  needed  to  support  the  development,  test, 
configuration  management,  and  documentation  of  the  Operational  Complex  and  to 
support  the  overall  management  of  the  System.  Explicit  Identification  of  Support 
Complex  software  allows  management  visibility  and  control  of  this  type  of  soft- 
ware, which  is  required  for  large,  complex  systems  but  which  is  often  neglected 
in  the  planning  stages  of  development.  Figure  1 shows  the  Operational  Complex 
of  the  System  divided  into  input,  processing,  and  output  phases,  together  with  the 
data  flow  between  those  phases.  The  data  base  maintenance  activity  shown  in  Fig- 
ure 1 is  one  of  the  activities  accomplished  in  the  Support  Complex  of  the  System. 

* V ' 

The  Operational  Complex  of  the  System  consists  of  10  Technology  Subsystems  and 
4 Executive  Subsystems.  The  Support  Complex  of  the  System  consists  of  four  sub- 
systems. 

The  elements  of  the  System  software  below  subsystem  in  the  hierarchy  are,  from 
the  top  down:  package,  subpackage,  and  module.  At  the  lowest  level  of  the  hier- 
archy is  the  basic  building  block  of  the  System — the  module.  A module  is  the 
equivalent  of  a FORTRAN  subprogram.  Modules  are  subject  to  constraints  of 
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Figure  2.  Top-Level  Hierarchy  of  the  System 
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programming  standards,  providing  management  control  and  limiting  maintenance 
costs.  In  the  middle  levels  of  the  hierarchy,  between  subsystem  and  module,  are 
the  packages  and  subpackages.  These  have  been  identified  as  Computer  Program 
Configuration  Items  (CPCIs)  for  the  Predesign  Phase. 

For  convenience,  the  collection  of  Technology  Subsystems  is  called  the  Technology 
Component,  and  the  collection  of  Executive  Subsystems  is  called  the  Executive 
Component. 


The  order  of  execution  of  the  software  elements  of  the  Technology  Component  and 
the  Executive  Component  and  the  selection  of  data  used  during  an  analysis  run  are 
specified  by  the  Sequence  Control  Table,  which  is  constructed  by  the  User  Input 
Package  (a  package  of  the  Executive  Component)  from  user  input  for  an  analysis 
run.  ("Software  element"  is  a general  phrase  used  to  denote  a member  at  any 
level  of  the  System  hierarchy,  usually  a package  or  a subpackage;  because  a pack- 
age or  a subpackage  may  in  certain  limited  instances  consist  of  only  one  module, 
a software  element  can  denote  a module. ) 

Communication  between  the  software  elements  listed  in  the  Sequence  Control 
Table  is  accomplished  by  allowing  a software  element  to  use  input  data  that  were 
calculated  by  another  software  element  earlier  in  the  execution  sequence.  Tech- 
nology Component  software  elements  have  the  capability  to  affect  the  execution  se- 
quence dynamically  by  issuing  to  the  Executive  Component  a System  Command  to 
be  executed  immediately.  Thus,  a software  element  is  able  to  issue  a command 
causing  the  Executive  Component  to  execute  a second  software  element  or  select 
additional  data  from  the  Run  Data  Base.  Upon  completion  of  the  System  Command 
execution,  the  software  element  Issuing  the  command  continues  to  operate  from  the 
point  immediately  following  the  point  at  which  the  command  was  Issued. 

The  Technology  Component  is  that  part  of  the  System  that  defines  the  mathematical 
analysis  for  the  entire  simulation.  Although  10  subsystems  are  currently  defined. 
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the  design  of  the  Technology  Component  Is  not  rigid;  i.e. , if  a new  capability  is 
defined  in  the  Type  A System  Specification,  either  it  is  allocated  to  an  existing  sub- 

l 

system  or  a new  subsystem  is  defined  to  accommodate  it.  The  principal  reasons 
for  defining  subsystems  are  to  provide  a management  control  tool  and  to  allow  for 

► 

unity  and  ease  of  documentation.  Because  of  the  ability  of  the  Executive  Compo- 
nent to  recognize  software  elements  independent  of  affiliation  with  a particular  sub- 
system, subsystems  may  be  added,  deleted,  or  reorganized  completely  without 
affecting  operation  of  the  System.  * 

The  executive  and  supervisory  control  of  System  data  and  software  during  an  anal-  \ 

ysis  run  is  localized  in  the  Executive  Component  of  the  Operational  Complex. 

The  Executive  Component  establishes  the  analyst's  interface  with  the  Operational 
Complex,  monitors  and  controls  the  execution  of  the  software  elements  during 
an  analysis  run,  manages  and  controls  the  data  needed  to  analyze  a helicopter 
configuration,  and  provides  a computer-independent  interface  to  host  operating 
system  services.  The  centralization  of  executive  and  supervisory  functions  mini- 
mizes the  complexity  and  extent  of  the  interfaces  among  the  software  elements  of 
the  7 echnology  Component.  This  permits  software  elements  of  the  Technology 
Component  to  be  developed  independently  and  in  parallel  by  multiple  subcontrac- 
tors. The  separation  of  executive  and  supervisory  functions  from  Technology 
Component  functions  ensures  that  the  goals  of  maximum  System  transportability 
and  minimum  computer  or  operating  system  dependency  are  realized. 

<y 

1 

1.3.4  A User's  Overview  of  System  Data 

t { 

System  data  are  divided  into  three  categories:  data  input  to  the  System,  data  used 
by  more  than  one  software  element  within  the  System,  and  data  output  from  the 
System. 

I 

Data  input  to  the  System  consist  of  three  principal  types:  the  Master  Data  Base, 
the  user  input,  and  the  Master  Command  File.  The  Master  Data  Base  contains 
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helicopter-oriented  data  likely  to  be  used  frequently  in  analysis  runs.  The  Master 
Data  Base  consists  of  sets  of  data  that  can  be  hierarchically  arranged  to  represent 
physical  configurations,  such  as  aircraft  or  components  of  aircraft,  to  represent 
flight  conditions  or  maneuvers,  and  to  represent  failure  or  damage  to  the  physical 
configuration. 

The  user  input  data  are  the  collection  of  statements  designed  for  use  by  a person 
with  no  knowledge  of  the  design  of  the  System  but  with  knowledge  of  the  physical 
configuration  to  be  analyzed.  The  form  of  the  user  input  emphasizes  the  descrip- 
tion of  the  configuration,  flight  conditions,  failure/damage  effects,  and  results  to  ' 

be  output.  Through  the  user  input  data,  the  Particular  Functional  Capability  spec- 
ified in  the  Type  A System  Specification  is  accessed. 

The  Master  Command  File  contains  sequences  of  System  Commands  that  are  the 
mechanism  for  controlling  the  steps  of  the  analysis.  The  System  Commands  are 
of  two  types:  the  execution  command,  which  causes  a specific  software  element  to 
be  executed;  and  the  sequence  control  command,  which  conditionally  causes  a 
transfer  of  control  within  the  sequence  of  System  Commands.  The  direct  creation 
and  modification  of  sequences  of  System  Commands  by  the  user,  e.g. , the  methods 

developer,  represents  the  General  Functional  Capability  of  the  System.  t > 

Data  used  by  more  than  one  software  element  within  the  System  are  contained  in 
the  Run  Data  Base.  The  Run  Data  Base  is  initialized  during  the  input  phase  of  an 
analysis  run  to  contain  all  input  data  required  for  the  processing  phase.  It  also 
contains  all  sets  of  data  that  are  generated  by  one  software  element  and  used  by 
another  during  the  course  of  the  analysis  run.  The  Run  Data  Base,  unlike  the 
Master  Data  Base,  is  a temporary  data  base  that  varies  from  run  to  run  and  is  not 
saved  at  the  end  of  an  analysis  run. 

. i ; 

Data  output  from  the  System  consist  primarily  of  printed  reports  and 'plots  of  the 
results  of  the  analysis.  Output  may  also  Include  prints  or  plots  of  intermediate 
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results  and  Information  such  as  intermediate  results  stored  in  restart  files  for 
potential  use  in  subsequent  analysis  runs. 

1.4  MAJOR  SYSTEM  DESIGN  CONSIDERATIONS:  USABILITY,  EFFICIENCY, 
TRANSPORTABILITY,  AND  EXTENDABILITY 

For  the  System  to  be  universally  accepted  by  the  helicopter  analysis  community, 
it  must  be  user-oriented,  efficient,  transportable,  and  extendable.  The  CSC/BHT 
design  synthesizes  a System  having  all  four  of  these  necessary  characteristics. 

1.4.1  Usability 

The  most  frequent  use  of  the  System  is  to  perform  a straightforward  analysis  of 
a physical  configuration  similar  to  one  in  the  Master  Data  Base.  The  Master  Data 
Base  is  a collection  of  data  at  each  installation  that  describes  aircraft,  aircraft 
components,  and  other  analysis  components  that  may  be  analyzed;  maneuvers, 
conditions,  and  operating  regimes  for  an  analysis;  and  failure/damage  effects  that 
might  be  considered.  It  is  the  intent  of  the  System  design  that  data  which  are  used 
repeatedly  in  analyses  at  an  installation  will  be  maintained  in  the  Master  Data 
Base  by  personnel  at  the  installation.  Each  helicopter  firm  and  Government 
agency  at  which  the  System  is  installed  can  configure  the  Master  Data  Base  to  suit 
its  own  needs.  Flight  conditions,  maneuvers,  and  operating  regimes  from  the 
Master  Data  Base  can  be  used  with  or  without  failure/damage  effects.  For  this 
mode  of  using  the  System,  a small  user  Input  data  deck  suffices  to  specify  the  de- 
sired analysis. 

To  provide  the  General  Functional  Capability  required  by  the  Baseline  Type  A 
System  Specification,  the  engineering  user  or  methods  developer  may  create 
directly  System  Commands  in  any  combination  and  in  any  order  (a  System  Com- 
mand identifies  the  software  element  to  be  executed  and  defines  its  required  in- 
put and  output).  To  produce  meaningful  results  however,  the  input  required  by  a 
software  element  must  have  been  calculated  prior  to  the  time  of  software  element 
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execution.  Thus,  the  use  of  the  System  in  this  manner  requires  a knowledge  of 
the  data  produced  by,  and  required  by,  the  software  element. 

The  System  may  be  used  from  an  interactive  terminal  to  prepare  valid  input  data, 
to  examine  previously  calculated  results,  and  to  execute  any  portion  (or  all)  of  the 
engineering  analysis  in  an  interactive  mode. 

Other  uses  of  the  System  are  to  support  the  engineer's  use  of  the  System.  The 
primary  supporting  use  of  the  System  is  to  maintain  the  Master  Data  Base.  Each 
installation  will  make  its  own  rules  for  Master  Data  Base  maintenance,  but  the 
recommended  procedure  is  to  test  all  data  before  including  it  in  the  Master  Data 
Base  and  to  include  in  the  Master  Data  Base  any  data  that  are  likely  to  be  used 
repeatedly. 

There  are  many  other  ways  to  use  the  System  in  support  of  its  primary  use.  For 
example,  upon  request  the  System  will  predict  the  cost  of  making  an  analysis  run 
to  assist  the  user  in  making  efficient  use  of  the  System.  For  another  example, 
the  System  can  be  used  to  make  changes  in  System  Command  Sequences  in  the 
Master  Command  File. 

As  users  become  more  familiar  and  more  confident  in  the  analysis  capabilities  pro- 
vided by  the  System,  enhancements  to  the  user's  interface  with  the  System  will  in- 
evitably be  recommended.  To  facilitate  incorporating  these  enhancements,  the 
direct  interface  to  the  user  is  defined  in  one  subsystem  of  the  Executive  Conti- 
nent, namely  the  User  Interface  Subsystem.  This  isolation  of  the  direct  user  in- 
terface from  the  rest  of  the  System  software  permits  the  user's  interface  to  be 
modified  without  requiring  attendant  changes  to  other  software  in  the  System. 

1.4.2  Efficiency 

The  System  is  designed  to  efficiently  analyze  both  small  problems  and  large  prob- 
lems. The  size  of  the  problem  is  not  restricted  by  the  amount  of  computer  mem- 
ory available  to  the  System.  However,  unlike  NASTRAN,  NASA's  Structural 
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Analysis  System,  the  Second  Generation  Comprehensive  Helicopter  Analysis  Sys- 
tem is  also  designed  to  efficiently  analyze  small  problems.  In  NASTRAN,  all  i 

problems  are  assumed  to  be  large,  thus  penalizing  the  efficiency  of  analyzing 
small  problems.  In  the  Second  Generation  Comprehensive  Helicopter  Analysis 
System,  two  design  features  are  included  which  emphasize  the  efficiency  of  small 
problem  analyses.  First,  the  Run  Data  Base  may  be  entirely  memory-resident 
(for  small  problems),  may  be  entirely  resident  on  peripheral  storage  device  (for 
large  problems),  or  may  be  partially  memory- resident  and  partially  peripheral  * 

device  resident  (for  intermediate-size  problems).  Second,  the  data  base  manage- 
ment services  provided  by  the  Data  Base  Management  Subsystem  of  the  Executive 
Component  are  designed  to  eliminate  any  dependency  of  Technology  Component 
software  elements  on  the  location  (i.e. , memory  or  peripheral  device)  of  data 
within  the  Run  Data  Base.  Thus,  the  fixed  input/output  overhead  penalty  incurred 
by  small  problems  in  NASTRAN  is  avoided  in  the  Second  Generation  Comprehensive 
Helicopter  Analysis  System. 

1.4.3  Transportability 

The  System  is  designed  to  be  transportable,  that  is,  to  be  transferred  to  a differ- 
ent computer  with  a different  operating  system  at  relatively  low  cost  and  in  a 
relatively  short  time  compared  to  the  time  ordinarily  required  to  convert  a sys- 
tem from  one  computer  to  another.  This  will  be  accomplished  in  the  Development 
Phase  when  both  the  First  Level  Release  and  the  Second  Level  Release  are  trans- 
ported from  the  Host  1 computer  (EBM  S/370  and  S/360  series)  vs  the  Host  2 com-  . 

puter  (CDC  6000  and  CYBER  series).  Having  both  releases  of  the  System  k 

available  on  the  two  computer  systems  most  widely  used  by  the  helicopter  analysis 

' 

community  will  contribute  to  the  System's  acceptance  by  both  helicopter  firms  and 
Government  agencies.  * 

I 

The  identification  oi  the  Operating  System  Service  Subsystem  as  one  of  the  Execu- 
tive Subsystems  is  the  aspect  of  the  design  that  allows  easy  transportability  of  the 
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System.  All  operating  system  services  for  the  remainder  of  the  System  are  per- 
formed by  the  Operating  System  Service  Subsystem.  The  interface  between  the 
Operating  System  Service  Subsystem  and  the  remainder  of  the  System  is  compu- 
ter independent  and  is  thus  unchanged  when  the  System  is  moved  to  a new  compu- 
ter. When  the  System  is  moved  to  a new  computer,  the  Operating  System  Service 
Subsystem  changes  to  use  the  new  host  operating  system  without  changing  its  in- 
terface with  the  rest  of  the  System.  Because  that  interface  is  not  changed,  the 
remainder  of  the  System  need  not  be  changed. 

1.4.4  Extendability 

The  system  is  designed  to  be  extendable  so  that  a methods  developer  can  easily 
experiment  with  new  or  improved  analysis  capabilities.  The  primary  features 
of  the  System  design  that  accomplish  this  goal  are  (1)  the  division  of  the  System 
into  software  elements  with  clearly  defined  functions  and  interfaces,  (2)  the  sepa- 
ration of  the  flow  of  control  from  the  logic  of  individual  software  elements,  and 
(3)  the  separation  of  data  management  from  the  logic  of  individual  software  ele- 
ments. 

The  definitions  of  the  function  performed  by  a software  element  and  its  interface 
with  the  rest  of  the  System  allow  easy  substitution  of  an  improved  software  ele- 
ment as  helicopter  analysis  and/or  software  technology  advances.  If  the  new 
software  element  requires  a different  interface,  the  extent  of  change  required  in 
other  software  elements  can  be  accurately  assessed. 

The  flow  of  control  for  a helicopter  analysis  is  defined  by  an  internal  sequence  of 
commands  in  the  Sequence  Control  Table  rather  than  in  the  logic  of  the  software 
elements.  Substitution  of  improved  (e.g. , more  accurate,  more  efficient)  soft- 
ware elements  or  introduction  of  new  software  elements  over  the  life  of  the  System 
thus  does  not  require  the  rewriting  of  other  software  elements  to  change  the  flow 
of  control  to  include  the  new  software  element.  Only  a sequence  of  System  Com- 
mands need  be  modified  to  include  the  new  software  element. 
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The  data  required  by  a software  element  are  specified  by  name  rather  than  by 
physical  location  on  a device  or  by  relative  location  within  a record.  Rearrange- 
ment of  data  as  necessary  or  convenient  during  the  life  of  the  System  Is  accom- 
plished without  change  to  the  software  elements  provided  the  data  names  are 
retained.  Reasons  for  data  rearrangement  during  the  life  of  the  System  include 
making  efficient  use  of  a particular  data  storage  device  and  adding  data  required 
by  or  produced  by  a new  software  element  implementing  an  Improved  analysis 
technique. 


SECTION  2 - SYSTEM  DESIGN  SUMMARY 


This  section  presents  a summary  of  the  System  designed  by  Computer  Sciences 
Corporation  (CSC)  and  Bell  Helicopter  Textron  (BHT)  to  meet  the  requirements  of 
the  Baseline  Type  A System  Specification  for  the  Second  Generation  Comprehensive 
Helicopter  Analysis  System,  CSC  Document  CSC/SD-7 8/6007.  Section  2, 1 pre- 
sents the  mathematical  basis  for  the  System.  Section  2.2  defines  the  terms  used 
to  describe  the  different  levels  of  the  software  system  hierarchy.  The  Operational 
Complex,  which  is  the  part  of  the  System  that  contains  the  software  that  solves 
helicopter  analysis  problems,  is  discussed  in  Section  2.3.  The  Support  Complex, 
which  aids  the  development,  test,  configuration  management,  and  documentation 
of  the  System,  is  discussed  in  Section  2.4.  The  section  concludes  with  a discussion 
in  Section  2. 5 of  the  System  Command  Sequences  for  the  five  aircraft  technical 
characteristics  of  performance,  stability  and  control,  loads  and  vibrations, 
acoustics,  and  aeroelastic  stability. 

2. 1 MATHEMATICAL  BASIS  FOR  THE  SYSTEM 

Three  goals  were  established  in  selecting  the  mathematical  basis  for  the  System 
design:  (1)  provide  a single  unifying  basis  for  the  analytical  solution  of  helicopter 
analysis  problems;  (2)  provide  a single  unifying  concept  ior  representing  both  heli- 
copter configuration  components  and  aerodynamic  effects;  and  (3)  provide  a method 
for  analyzing  a physical  configuration  composed  of  independently  defined  compo- 
nents. A unified  approach  has  been  formulated  which  provides  a consistent  repre- 
sentation of  the  differential  equations  required  for  helicopter  analysis  and 
simulation,  a consistent  method  for  representing  physical  components  (namely, 
finite  elements),  and  a systematic  method  for  coupling  components  which  represent 
a physical  configuration.  Section  2. 1. 1 contains  a discussion  of  the  type  of  prob- 
lems that  are  to  be  solved  by  the  System  and  the  mathematical  solution  of  these 
problems.  Section  2. 1.2  discusses  the  applicability  of  the  finite  element  concept 
to  the  representation  of  helicopter  configurations.  Section  2.1.3  deals  with  the 


43 


important  problem  of  coupling  of  components;  to  reduce  computer  costs,  the 
method  of  component  modes  was  incorporated  in  the  design  for  the  First  Level  Re- 
lease of  the  System.  Section  2. 1. 4 discusses  the  equally  important  problem  of 
aerodynamic  effects.  Section  2. 1. 5 presents  numerical  analysis  considerations 
important  to  the  reliability  and  acceptability  of  the  System.  Finally,  Section  2. 1. 6 
describes  how  the  modularity  and  adaptability  of  the  System  design  accommodate 
innovative  analysis  concepts  related  to  helicopter  technology  without  necessitating 
major  design  modifications  and  at  relatively  little  cost. 

2.1.1  Type  of  Problems  To  Be  Solved  by  the  System 

The  System  to  be  developed  is  required  to  predict,  accurately  and  reliably,  the 
performance,  stability  and  control,  loads  and  vibrations,  acoustics,  and  aero- 
elastic  stability  characteristics  of  rotary-wing  aircraft  configurations.  The 
proposed  System  must  therefore  be  capable  of  solving  all  problems  associated 
with  these  five  aircraft  technical  characteristics. 

In  its  most  general  form,  helicopter  analysis  and  simulation  can  be  represented 
by  a system  of  second-order  differential  equations  in  the  form  of  the  following 
matrix  equation: 

[M]  {q]  + [C]  {q}  + [K]  £q}  = [F]  (2) 

where  (q)  , {q}  , and  [q]  are  generalized  displacement,  velocity,  and  accel- 
eration vectors,  respectively;  [M]  , [C]  , and  [K]  are  the  mass,  damping, 
and  stiffness  matrices,  respectively,  of  the  aircraft  configuration  under  analy- 
sis (these  matrices  maybe  constant,  periodic,  or  otherwise  time  variant,  or 
weak  functions  of  {q}  and  {q})  ; and  [F}  is  a vector  of  generalized  forces 
that  may  be  constant  but  is  more  commonly  periodic  or  otherwise  time  variant. 

In  addition,  [F } may  be  a linear  or  nonlinear  function  of  the  [q]  and  [q] 
vectors. 


44 


For  numerical  processing.  Equation  (2)  can  be  transformed  into  a set  of  first- 
order  differential  equations  using  the  following  transformation: 


Cp1}  = [q] 

{p2}  = [q]  = (p13 

Using  these  transformations  in  Equation  (2)  yields 
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where  I is  the  identity  matrix. 

In  general,  transformations  of  the  type  in  Equation  (3)  can  be  employed  to  trans- 
form any  given  set  of  higher  order  differential  equations  into  a set  of  first-order 
differential  equations  of  the  type  in  Equation  (4).  In  this  way,  the  System  can  be 
adapted  for  the  numerical  processing  of  higher  order  differential  equations  also. 

The  degrees  of  freedom  represented  by  the  [q]  vector  mentioned  above  are 
called  the  analysis  degrees  of  freedom.  These  can  represent  a variety  of  phys- 
ical or  convenient  mathematical  quantities.  In  the  analysis  of  structural  com- 
ponents, these  can  represent  either  physical  displacements  at  the  node  points 
or  modal  coordinates.  Other  types  of  analysis  degrees  of  freedom  can  include 
fluid  pressures  and  flow  rates  for  a hydraulic  actuator  or  control  motions  and 
derivatives  for  an  electronic  flight  control  system. 

All  helicopter  problems  to  be  analyzed  by  the  System  can  be  represented  either  by 
Equation  (2)  or  by  derivations  thereof.  Problems  that  require  time-history  solu- 
tions, such  as  aircraft  maneuvers  with  prescribed  control  motions  or  prescribed 


responses,  and  flight  simulations  involving  atmospheric  disturbances  or  failure/ 
damage  effects,  are  examples  of  problems  that  can  be  represented  by  the  general 
form  of  Equation  (2).  A time-history  solution  is  obtained  by  a direct  numerical 
integration  of  Equation  (2). 

Basic  to  many  helicopter  analysis  problems  is  the  determination  of  the  steady- 
state  flight  or  trim  for  various  prescribed  flight  conditions.  Many  of  the 
conditions  of  interest  for  performance,  stability  and  control,  loads  and  vibra- 
tions, and  acoustics  are  steady-state  trim  conditions.  Several  critical  helicop- 
ter design  considerations  which  can  be  analyzed  during  a steady-state  flight 
condition  include  the  effects  of  airspeed  variation  on  power  required,  control 
positions,  oscillatory  bending  moments  or  stresses,  cabin  area  vibrations,  and 
perceived  noise  levels  inside  the  aircraft  as  well  as  on  the  ground. 

In  most  cases,  steady-state  flight  can  be  regarded  as  the  response  to  a force 
input  that  varies  harmonically.  The  matrix  equation  for  steady-state  flight  can 
therefore  be  represented  by 

[M]£q]  + [C]£q]  + [K][q}  = [f  J sin  Wt  (5) 

which  is  obtained  from  Equation  (2)  by  setting  [f]  = [f]  sin  u>t  , where  the  vector 
£f}  is  a function  of  [q]  and  [q]  as  well  as  the  flight  conditions,  u>  is  the  forcing 
frequency,  and  t represents  time. 

Because  £f}  is  a function  of  {qj  and  {q]  , the  trim  condition  problem  repre- 
sented by  Equation  (5)  requires  iterative  techniques  in  order  to  be  able  to  converge 
to  the  trimmed  state.  Before  a trim  computation  can  be  attempted,  certain  as- 
sumptions about  the  form  of  the  solution  must  be  made  based  on  the  complexity  of 


the  matrix  equations  selected  for  the  solution.  In  the  general  case,  the  trim  solu- 
tion can  be  assumed  to  be  a truncated  Fourier  series  solution  in  which  the  funda- 
mental frequencies  are  the  rotational  speeds  of  the  rotors  and  the  number  of 
harmonics  to  be  computed  is  specified  by  the  user.  This  is  represented  by 
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where  n is  the  number  of  harmonics  specified  by  the  user.  The  coefficients  of 
the  harmonics  are  determined  by  substituting  Equation  (6)  into  Equation  (5)  and 
using  the  method  of  undetermined  coefficients.1  For  a simple  case,  only  the  re- 
sponse due  to  the  constant  term  and  the  first  harmonic  need  be  considered.  This 
reduces  the  number  of  periodic  coefficients  in  the  matrix  equations,  thus  simplify- 
ing the  solution.  For  the  most  elementary  case,  the  periodic  coefficients  can  be 
neglected  entirely  so  that  only  the  response  due  to  the  constant  term  is  calculated. 

In  the  case  of  highly  nonlinear  mathematical  models,  the  assumption  of  har- 
monic response  may  be  significantly  in  error.  For  these  circumstances,  the 
design  Includes  a fly-to-trim  option.  This  option  is  designed  to  calculate  the  true 
nonlinear  response  for  a steady-state  flight  condition  in  a manner  very  similar  to 
a flight  test  procedure. 


1Kreyszig,  E. , ADVANCED  ENGINEERING  MATHEMATICS,  New  York,  John  Wiley 
and  Sons,  1967. 
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Another  fundamental  problem  In  helicopter  analysis  is  the  determination  of  the 
natural  frequencies  and  mode  shapes  of  the  aircraft  structure  and  its  compo- 

i 

nents.  This  problem  is  represented  by  the  simple  and  familiar  equation 

[M](q]  + [K]Cq}  - [0]  (7) 

which  is  obtained  from  Equation  (2)  by  setting  [c]  = [o]  and  [f]  = £0 } . The 
solution  to  this  equation  yields  eigenvalues  and  eigenvectors  (natural  frequen- 

% 

cies  and  mode  shapes)  of  the  component  or  configuration  in  a vacuum  (without 
air  loads). 

Stability  and  control  analysis  and  aeroelastic  stability  analysis  can  both  be 
performed  by  considering  small  perturbed  motions  about  a trimmed  flight  con- 
dition. The  primary  difference  between  stability  and  control  analysis  and 
aeroelastic  stability  analysis  lies  in  the  level  of  detail  and  the  type  of  config- 
uration considered.  Stability  and  control  analysts  are  primarily  interested  in 
rigid-body  aircraft  motions  and  responses  to  cockpit  control  motions.  The 
handling  qualities  of  the  aircraft  are  judged  by  the  rigid-body  behavior  of  the 
fuselage  whether  the  simulation  model  used  is  a simple  one  or  a fully  aero- 
elastic representation.  ^ 

On  the  other  hand,  in  the  case  of  aeroelastic  stability  analysis,  complex  dy- 
namic coupling  and  unsteady  aerodynamics  are  the  essential  ingredients,  and 

. -I 

the  airframe  itself  may  be  of  secondary  importance.  Investigations  of  classical 

flutter  and  stall  flutter  on  a rotor  are  examples  of  aeroelastic  stability  analyses 
that  are  independent  of  the  airframe.  In  contrast,  ground  resonance  and  whirl 
flutter  are  aeroelastic  stability  problems  that  involve  both  rotors  and  airframe. 

1 

As  a final  example,  the  phenomenon  of  air  resonance  is  one  in  which  the  fields  r 

of  aeroelastic  stability  and  stability  and  control  truly  intertwine. 


2 3 

Stability  analysis  involves  the  computation  of  stability  derivatives,  ’ some  of 
which  are  calculated  by  using  Equation  (2).  The  derivatives  may  be  calculated 
either  analytically  or  numerically.  These  stability  derivatives  are  then  used  to 
set  up  locally  linearized  equations  of  motion  of  the  form 

[M'l{q]  + [C'lCq]  + [K'][q]  = [F')  (8) 


where  coefficient  matrices  [M']  , [Cl  , and  [K']  and  vector  [F1]  involve 
stability  derivatives.  The  coefficient  matrices  in  this  equation  are  constant 
for  classical  stability  analysis  and  periodic  for  Floquet  analysis. 

Stability  analysis  normally  leads  to  the  standard  eigenvalue  problem  represented 
by  the  equation 


[A  - XI] 


Co} 


(9) 


where  [A]  is  a square  matrix,  X is  a scalar  quantity  (real  or  complex),  and 
[i]  is  a unit  matrix.  The  eigenvalues  (the  Xs)  of  [A]  characterize  the  sta- 
bility of  the  physical  configuration.  Mode  shapes  corresponding  to  these  char- 
acteristic values  indicate  the  type  of  motion  associated  with  each  stable  or 
unstable  eigenvalue. 

Aircraft  maneuvers  with  prescribed  controls  or  prescribed  responses  and  flight 
simulations  during  which  there  are  sudden  changes  of  atmospheric  conditions  or 
sudden  structural  changes  caused  by  loss  of  components  or  failure/damage  effects 


2Seckel,  E. , STABILITY  AND  CONTROL  OF  AIRPLANES  AND  HELICOPTERS, 
New  York,  Academic  Press,  1968. 

3Bramwell,  A.  R.  S. , HELICOPTER  DYNAMICS,  New  York,  John  Wiley  and  Sons, 
1976. 
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are  examples  of  problems  that  can  be  represented  by  the  general  form  given  by 

Equation  (2).  The  solutions  to  these  transient  problems  require  the  generation  of  i 

time  histories  of  the  vector  [q]  by  numerical  integration  techniques.  To  start 

these  time-history  solutions,  it  is  first  necessary  to  have  a realistic  set  of  initial 

conditions.  These  initial  conditions  may  be  obtained  either  from  user  input  or  from 

the  results  of  a previously  calculated  trim  condition. 

Predictions  of  performance,  loads  and  vibrations,  and  acoustics  characteristics 
need  not  be  regarded  as  special  mathematical  procedures  because  these  charac- 
teristics can  be  determined  as  a byproduct  of  the  normal  processing  for  a trimmed 
flight  condition  or  at  time  points  during  a transient  solution. 

2.1.2  Finite  Element  Concept 

The  generation  of  the  mass,  damping,  and  stiffness  matrices  shown  in  Equation  (2) 

can  be  a very  complex  process  for  a complex  configuration  like  a helicopter.  The 

finite  element  concept,  which  is  a very  systematic  and  unifying  method  of  analysis, 

4 5 6 

lends  itself  very  well  to  reducing  this  complexity.  This  method  of  analysis  * ' 
has  been  successfully  employed  in  structural  analysis  applications  for  many  years. 


4 

Desai,  C.  S. , and  Abel,  J.  F. , INTRODUCTION  TO  THE  FINITE  ELEMENT 
METHOD,  New  York,  Van  Nostrand  Reinhold  Company,  1972. 

5 

Brebbia,  C.  A. , and  Connor,  J.  J. , FUNDAMENTALS  OF  FINITE  ELEMENT 
TECHNIQUES,  New  York,  John  Wiley  and  Sons,  1974. 

6 

Gallagher,  R.  H. , FINITE  ELEMENT  ANALYSIS  FUNDAMENTALS,  Englewood 
Cliffs,  New  Jersey,  Prentice-Hall,  Inc. , 1975. 
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In  recent  years,  the  suitability  and  adaptability  of  this  method  for  the  analysis  of 
both  nonrotating  and  rotating  components  of  a helicopter  have  been  demon- 
strated.7’8’9 

The  use  of  the  finite  element  concept  is  the  basis  of  the  System  design.  This  unify- 
ing and  systematic  concept  makes  it  possible  for  the  System  to  analyze  varieties 
of  helicopter  configurations  and  designs  without  radically  changing  the  basic  struc- 
ture of  the  System.  This  concept  also  makes  it  possible  to  analyze  complex  indi- 
vidual helicopter  structures  (such  as  a complete  fuselage,  a complete  rotor,  and 
an  engine  or  an  electronic  flight  control  system)  independently  before  they  are 
combined  to  form  the  aircraft  configuration.  This  concept  also  permits  the  use  of 
specialized  analysis  techniques  for  handling  particular  components  of  a helicopter. 

The  design  treats  the  aircraft  configuration  as  a collection  of  aircraft  and  other 
analyses  components  that  are  represented  by  finite  elements  connected  together  at 
specified  locations  called  node  points.  The  behavior  of  the  total  configuration  is 
then  derived  from  the  analysis  of  the  individual  components  that  constitute  the  con- 
figuration. 

The  degrees  of  freedom  involved  in  the  analysis  (the  components  of  the  [q] 
vector  in  Equation  (2))  are  called  the  analysis  degrees  of  freedom.  In  the  direct 
method  of  finite  element  analysis,  these  degrees  of  freedom  are  the  physical 


7Cronkhite,  J.  D.,  DEVELOPMENT,  DOCUMENTATION  AND  CORRELATION  OF 
A NASTRAN  VIBRATION  MODEL  OF  THE  AH-1G  HELICOPTER  AIRFRAME, 
NASTRAN:  User's  Experiences,  NASA  TM  X-3428,  October  1976,  pp.  273-294 
(see  also  Reference  8). 

8Pamidi,  P.  R. , and  J.  D.  Cronkhite,  ADDITION  OF  RIGID  ELEMENTS  TO 
NASTRAN,  Sixth  NASTRAN  Users'  Colleaulum.  NASA  Conference  Publica- 
tion 2018,  October  1977,  pp.  449-468. 

9Krishna  Murthy,  A.  V. , and  Sridhara  Murthy,  S. , FINITE  ELEMENT  ANALYSIS 
OF  ROTORS,  Mechanism  and  Machine  Theory,  Vol.  12,  1977,  pp.  311-322. 
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displacements  at  the  node  points.  In  the  modal  method  of  finite  element  analysis, 
these  degrees  of  freedom  are  the  modal  coordinates. 

The  node  points  employed  may  be  either  dynamic,  aerodynamic,  or  both.  Provid- 
ing this  capability  can  reduce  computing  costs  by  avoiding  unnecessary  aerodynamic 
calculations  at  points  where  the  airloads  are  insignificant  and  unnecessary  dynamic  * 

calculations  at  points  where  dynamic  effects  are  insignificant.  (In  aerodynamic  ap- 
plications, the  best  aerodynamic  model  is  normally  defined  quite  differently  from 
the  structural  dynamic  model  with  which  it  is  connected.  Section  2. 1.4  discusses  ’ 

how  aerodynamic  effects  can  be  represented  by  using  aerodynamic  models. ) 

2.1.3  Coupling  of  Components 

The  System  must  be  capable  of  handling  a variety  of  aircraft  and  other  com- 
ponents combined  to  form  a variety  of  configurations.  A general  and  systematic 
method  for  coupling  various  components  is  therefore  crucial  to  the  success  and 
acceptability  of  the  System. 

Coupling  of  components  (sometimes  called  dynamic  coupling)  can  be  regarded 
as  a logical  extension  of  the  finite  element  concept  discussed  in  the  previous 
section.  Thus,  just  as  finite  elements  are  combined  to  result  in  a structure 

or  component,  structures  or  components  in  turn  can  be  dynamically  coupled  1 ' 

to  yield  complex  structures  or  configurations. 

A general  and  systematic  method  for  coupling  components  reduces  considerably 

the  amount  of  work  required  to  combine  components  that  have  already  been  ‘ 

separately  derived  and  tested.  This  procedure  of  combining  components  is  » 

particularly  applicable  to  the  coupling  of  rotating  components  with  components 
of  the  fixed  system  and  is  therefore  well  suited  to  the  treatment  of  the  helicop- 
ter analysis  problem.  * 
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To  effectively  serve  the  needs  of  the  helicopter  analysis  community,  the  method 
of  coupling  employed  in  the  System  must  satisfy  the  following  three  important 
criteria: 

1.  It  must  employ  a minimum  number  of  degrees  of  freedom. 

2.  It  must  permit  totally  independent  analysis  of  the  components. 

3.  It  must  be  compatible  with  test  procedures  in  order  to  facilitate 

• comparison  with  test  results. 

Consider  a configuration  made  up  of  n components.  The  behavior  of  any  com- 
ponent i can  then  be  represented  by  the  matrix  differential  equation 

[M.]  [p.}  + [c.3  [p.3  + [K.]  [p.}  = [F.]  (10) 

where  [Mj]  , [C.]  , and  [K.]  are  the  mass,  damping,  and  stiffness  matrices 
of  component  i;  {F.}  represents  the  forces  acting  on  the  component;  and  [p.) 
represents  the  degrees  of  freedom  associated  with  the  component. 

The  following  matrix  equation  represents  the  mass,  damping,  and  stiffness 
matrices  for  all  the  components  In  an  uncoupled  configuration: 
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which,  in  condensed  form,  can  be  represented  as 
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[Mu]  [p]  + [Cu]  Cf»3  + [Ku]  [p}  = CFu]  (12) 

Equations  (11)  and  (12)  represent  a disjoint  or  uncoupled  configuration  made  up  of 
the  n components.  Coupling  the  components  implies  certain  relationships  among 
the  vectors  CPj  3 , (p23  .....  CPj}  .....  and  CPn3  • These  relationships  can 
be  expressed  by  a matrix  relationship  of  the  form  • 


where  {q]  is  the  vector  that  represents  the  degrees  of  freedom  of  the  coupled 
configuration  as  in  Equation  (2),  and  any  partition  [/3j]  of  [/3]  is  a transforma- 
tion matrix  that  relates  the  degrees  of  freedom  Cp^3  of  component  i to  the 

degrees  of  freedom  {qj  of  the  coupled  configuration.  Normally,  the  degrees  i 

of  freedom  represented  by  (q)  for  the  coupled  configuration  represent  a sub-  x 

set  of  the  degrees  of  freedom  represented  by  Cp3  for  the  uncoupled  configura- 

. 

tion.  Laj  can  be  assumed  to  be  time  invariant  without  any  loss  of  generality. 

This  is  not  an  undue  restriction  on  the  modeling  because  transformations  associated  ' 

with  rotating  coordinate  systems  are  performed  within  individual  component  repre- 
sentations before  such  components  are  coupled  together. 
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Substitution  of  Equation  (13)  in  Equation  (12)  and  premultiplication  of  the  resultant 
T 

relationship  by  [0]  yield  the  matrix  equation 

[M]{q}  + [C](q}+[K][q]  = [F]  (14) 


where  the  coefficient  matrices  are  given  by 


[m]  = [0]t[mu]  [0] 
lcl  = lfi?  Ccu][0] 
[K]  = G8]t  Cku3  [0] 


and 


{f)=D8]t[fu3 

Note  that  Equation  (14)  is  the  same  as  Equation  (2). 

Coupling  of  components  can  be  accomplished  by  two  different  methods.  The  first 
method  is  commonly  referred  to  as  substructure  analysis.  One  of  the  earliest 
comprehensive  discussions  of  this  method  was  presented  by  Przemieniecki.1^ 

The  second  method,  commonly  called  the  method  of  component  modes,  was  first 


^Przemieniecki,  J.  S. , 
AIAA  Journal,  Vol.  1, 


MATRIX  STRUCTURAL  ANALYSIS  OF  SUBSTRUCTURES, 
No.  1,  January  1963,  pp.  138-147. 
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11  12 

proposed  by  Hurty.  ’ This  method  and  others  derived  from  it  have  since  re- 

, , , ^ . . . ..  . . . 13  through  25 

ceived  much  attention  in  the  aerospace  industry. 


llHurty,  W.  C.,  VIBRATIONS  OF  STRUCTURAL  SYSTEMS  BY  COMPONENT  MODE  SYN- 
THESIS, Proc.  ASCE,  Journal  of  the  Engineering  Mechanics  Division.  August  1060, 
pp.  51-69. 

Hurty,  W.  C.,  DYNAMIC  ANALYSIS  OF  STRUCTURAL  SYSTEMS  USING  COMPONENT 
MODES,  AIAA  Journal,  Vol.  3,  No.  4,  April  1965,  pp.  678-685. 

l3Gladwell,  G.  M.  L. , BRANCH  MODE  ANALYSIS  OF  VIBRATING  SYSTEMS,  Journal  of 
Sound  and  Vibration.  Vol.  1,  1964,  pp.  41-59. 

14Bamford,  R.  M. , A MODAL  COMBINATION  PROGRAM  FOR  DYNAMIC  ANALYSIS  OF 
STRUCTURES,  NASA  TM  33-290,  Jet  Propulsion  Laboratory,  1966. 

15Bajan,  R.  L.,  and  Feng,  C.  C. , FREE  VIBRATION  ANALYSIS  BY  THE  MODAL  SUBSTI- 
TUTION METHOD,  American  Astronautics  Society  Symposium.  Paper  No.  68-8-1, 

July  1968. 

1GBenfield,  W.  A.,  and  Hruda,  F.  R.,  VIBRATION  ANALYSIS  OF  STRUCTURES  BY  COM- 
PONENT SUBSTITUTION,  AIAA  Journal.  Vol.  9,  July  1971,  pp.  1255-1261. 

17Hintz,  R.  M.,  ANALYTICAL  METHODS  IN  COMPONENT  MODAL  SYNTHESIS,  AIAA 
Journal.  Vol.  13,  August  1975,  pp.  1007-1016. 

18 

Craig,  R.  R.,  Jr.,  and  Bampton,  M.  C.  C.,  COUPLING  OF  SUBSTRUCTURES  FOR 
DYNAMIC  ANALYSES,  AIAA  Journal.  Vol.  6,  No.  7,  July  1968,  pp.  1313-1319. 

19MacNeal,  R.  H.,  A HYBRID  METHOD  OF  COMPONENT  MODE  SYNTHESIS,  Computers 
and  Structures.  Vol.  1,  December  1971,  pp.  581-601. 

2°Rubin,  S.,  AN  IMPROVED  COMPONENT-MODE  REPRESENTATION,  AIAA  Paper  No. 

74-386,  presented  at  AIAA/ASME/SAE  15th  Structures,  Structural  Dynamics  and  Mate- 
rials Conference,  Las  Vegas,  Nevada,  April  17-19,  1974. 

21Gieseke,  R.  K.,  ANALYSIS  OF  NONUNEAR  STRUCTURES  VIA  MODE  SYNTHESIS, 

NASTRAN:  Users'  Experiences:  NASA  TM  X-3278,  September  1976,  pp.  341-360. 

22 

Klosterman,  A.  L. , A COMBINED  EXPERIMENTAL  AND  ANALYTICAL  PROCEDURE 
FOR  IMPROVING  AUTOMOTIVE  SYSTEM  DYNAMICS,  Society  of  Automotive  Engineers. 

Paper  No.  720093,  January  1972.  , 

21 

McClelland,  W.  A.,  and  Klosterman,  A.  L.,  USING  NASTRAN  FOR  DYNAMIC  ANAL- 
YSIS OF  VEHICLE  SYSTEMS,  Society  of  Automotive  Engineers.  Paper  No.  740326, 

March  1974. 

24Hertlng,  D.  N.,  and  Hoealy,  R.  L. , DEVELOPMENT  OF  AN  AUTOMATED  MULTI- 
STAGE MODAL  SYNTHESIS  SYSTEM  FOR  NASTRAN,  Sixth  NASTRAN  Users'  Colloquium. 

NASA  Conference  Publication  2018,  October  1977,  pp.  435-448. 

26 

Wilson,  T.  L. , A NASTRAN  DMAP  ALTER  FOR  THE  COUPUNG  OF  MODAL  AND 
PHYSICAL  COORDINATE  SUBSTRUCTURES,  Sixth  NASTRAN  Users'  Colloquium.  NASA 
Conference  Publication  2018,  October  1977,  pp.  119-130. 
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Ip  both  of  these  methods,  a complex  structure  is  considered  to  be  made  up  of  com- 
ponent  substructures  connected  at  specified  node  points,  and  the  behavior  of  the 

i 

structure  is  determined  by  considering  the  behavior  of  the  component  substructures 
at  the  connection  node  points.  The  essential  difference  between  the  two  methods 
lies  in  the  different  manner  in  which  the  behavior  of  the  component  substructures 
(namely,  the  vectors  {p  ; , {p  ] , ..  . in  Equations  (11)  and  (13))  is  represented. 

X Ld 

In  substructure  analysis,  the  component  substructures  are  represented  by  the 

physical  displacements  at  the  connecting  node  points,  whereas,  in  the  component 

modes  method,  the  substructures  are  represented  by  their  modal  data  (eigenvalues 

and  eigenvectors).  The  chief  advantage  of  the  component  modes  method  over  the 

substructure  analysis  method  is  that  reliable  results  can  normally  be  obtained  using 

significantly  fewer  degrees  of  freedom  than  are  needed  in  substructure  analysis. 

This  advantage  leads  to  cost  savings.  Also,  the  component  modes  method  does  not 

require  that  the  modal  data  be  generated  only  by  analytical  methods;  some  or 

22 

all  data  can  be  derived  from  experimental  data. 

Several  approaches  to  the  use  of  component  modes  have  been  proposed  by  various 
investigators.  The  approach  suggested  by  Hurty,  * and  variations  of  it  pro- 
posed by  others,14  trough  employ  rigid-body  modes,  constraint  modes,  and 
normal  modes  with  fixed  constraints.  These  approaches  are  incompatible  with 

helicopter  test  procedures  and  therefore  make  it  quite  difficult  to  compare  analy- 

? 19  20 

sis  results  with  test  data.  The  approaches  proposed  by  MacNeal  and  Rubin 
employ  free-body  modes  and  residual  effects.  Both  MacNeal's  and  Rubin's  ap- 
proaches give  good  accuracy  (this  is  particularly  so  for  Rubin's  approach,  which 
is  an  improvement  over  MacNeal's  approach),  but  both  are  restrictive  and  cumber- 
some in  formulation.  More  recently,  a general  component  modes  approach  for  in- 

24 

elusion  in  NASTR  AN  has  been  developed  under  NASA  sponsorship.  This  approach 

20 

has  the  accuracy  of  Rubin’s  method  without  the  restriction  of  having  to  use  speci- 
fic types  of  modes.  In  addition,  all  other  methods  mentioned  above  can  be  re- 
garded as  special  cases  of  this  general  approach. 
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This  component  modes  approach  also  satisfies  all  the  three  criteria  mentioned 

earlier  for  a systematic  method  of  coupling  components.  Therefore,  the  compo-  , 

nent  modes  approach  developed  for  inclusion  in  NASTRAN  is  the  approach  best 
suited  for  inclusion  in  the  System. 

The  System  design  can  accommodate  either  of  the  two  dynamic  coupling  methods 

mentioned  above  (i.e.,  substructure  analysis  or  component  modes).  However, 

the  funds  available  for  the  Development  Phase  may  not  permit  the  implementation 

of  both  methods.  Because  of  the  advantages  offered  by  the  component  modes  • 

method,  CSC  recommends  the  implementation  of  this  method  of  coupling  for  the 

First  Level  Release  of  the  System.  If  funding  permits,  it  is  recommended  that 

the  substructure  analysis  method  be  added  to  the  Second  Level  Release  of  the 

25 

System.  It  is  also  recommended  that  the  simultaneous  use  of  both  these  methods 
be  considered  for  inclusion  in  the  Long  Range  System. 

2.1.4  Aerodynamic  Effects 

The  proper  treatment  of  the  aerodynamic  flow  field  and  its  effect  upon  the  var- 
ious components  of  the  helicopter  is  one  of  the  most  important  requirements 
of  the  System.  As  a starting  point,  it  must  be  realized  that  the  airmass  sur- 
rounding the  aircraft  is  a continuum  that  comes  into  physical  contact  with 
every  node  point  of  the  aircraft.  Thus,  for  the  most  rigorous  analysis  (e.  g. , 
for  research  applications),  the  coupling  of  every  node  point  with  every  other 
node  point  through  the  aerodynamic  velocity  and  pressure  field  must  be  con- 
sidered. In  addition,  the  inherent  nonlinearities  of  both  steady  and  unsteady 
aerodynamics  in  subsonic  and  transonic  flow  must  be  considered.  » 

In  general,  the  aerodynamic  effects  cannot  be  easily  accounted  for  by  consider- 
ing additional  independent  degrees  of  freedom  in  the  [q]  vector  of  Equation  (2). 

The  normal  practice  is  to  account  for  the  aerodynamic  effects  by  including  them 
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in  the  fF}  vector  in  Equation  (2)  as  well  as  by  relating  them  to  the  structural 
dynamic  degrees  of  freedom  in  the  [q)  vector.  However,  for  certain  simplified 
models  of  induced  velocity,  it  is  possible  to  include,  in  the  independent  degrees  of 
freedom,  variables  which  describe  the  time-averaged  induced  velocity  field  and 
which  approximate  the  lower  harmonics  of  induced  velocity.  Also,  in  potential  flow 
solutions,  the  element  strengths  and  vortex  positions  are  treated  as  analysis 
degrees  of  freedom. 

Different  applications  require  different  simplifying  assumptions  about  the  aero- 
dynamic effects.  In  particular,  there  is  a sharp  contrast  between  the  aero- 
dynamic analysis  used  for  preliminary  design  and  that  used  for  research 
applications.  To  facilitate  the  application  of  differing  assumptions  about  aero- 
dynamic effects,  two  distinct  models  of  aerodynamic  effects  have  been  identified: 
aerodynamic  force  models  and  aerodynamic  interference  models. 

Aerodynamic  force  models  are  used  to  represent  the  forces  exerted  by  the 
surrounding  fluid  on  the  aircraft  structure.  These  models  can  represent  non- 
linear analytic  or  tabular  functions.  A typical  aerodynamic  force  model  rep- 
resents the  steady  lift,  drag,  and  pitching  moment  for  an  aerodynamic  node 
point  on  the  rotor.  The  functional  form  for  such  a representation  is 


Lt  = L((q}»  tq},  t) 
Dj  = D({q],  {q},  t) 
= M(lq),  {q},  t) 


where  i is  an  aerodynamic  node  point,  Li  is  the  lift  force,  is  the  drag 
force,  is  the  pitching  moment,  and  the  functions  L , D , and  M include 
calculation  of  velocity  components,  aerodynamic  angles,  Mach  number,  dynamic 
pressure,  and  analytic  or  tabular  evaluation  of  aerodynamic  coefficients.  It 
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should  be  emphasized  that  the  aerodynamic  force  models  can  represent  not  only 
linear  aerodynamics  effects,  but  also  nonlinear  effects. 


Aerodynamic  Interference  models  represent  the  direct  aerodynamic  coupling 
between  aircraft  components  that  occurs  through  the  airmass.  Aerodynamic 
interference  models  may  represent  one-way  effects,  as  in  the  rotor-induced 
downwash  on  a wing.  They  may  also  represent  mutual  interference  effects,  as 
in  the  downwash  effects  for  a tandem  helicopter,  which  account  for  the  effect 
of  each  rotor  on  the  other  simultaneously. 


The  functional  form  for  an  aerodynamic  interference  model  that  represents 
rotor  downwash  on  a wing  is  as  follows: 


VR/W  = V(Li’  Di’  Ml  [tOT  aU  I}’  t} 


(16) 


where  is  the  velocity  vector  for  the  flow  induced  by  the  rotor  at  the 


wing,  and  V represents  a function  of  the  rotor  forces  and  moments  depending 
on  the  spatial  relationship  between  the  rotor  and  wing  and  allowing  for  a time 
delay  for  velocity  changes. 


Wake  analysis  and  aerody  namic  panel  representations  are  other  types  of  aero- 
dynamic interference  models. 


2.1.5  Numerical  Analysis  Considerations 

While  the  numerical  stability  of  integration  procedures  is  very  important  to  the 
reliability  of  the  System,  the  Project  team  believes  that  other  important  areas  of 
numerical  analysis  must  be  successfully  addressed  if  the  System  is  to  be  accept- 
able. Other  important  numerical  analysis  considerations  include  coordinate 
systems  and  transformations,  stability  and  control  and  aeroelastic  stability  com- 
putations, solution  of  trim  equations,  interpolation,  and  statistical  analysis  and 
digital  filtering. 
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The  Project  team  has  considered  possible  numerical  analysis  problems  in  two 
ways.  First,  the  design  of  the  System  has  been  made  independent  of  single  numer- 
ical methods.  Second,  the  combined  experience  of  both  companies  has  been  used 
to  address  specific  numerical  methods  for  this  application. 

2. 1. 5. 1 Numerical  Integration 

• 

The  Project  team  has  conducted  much  analysis  in  determining  the  "best"  numerical 
integration  techniques  for  application  to  flight  dynamics  problems.  BHT  has 
found  that  no  predictor-corrector  technique  (such  as  Hamming's  method,  which 
was  at  one  time  implemented  in  C81)  could  tolerate  the  discontinuities  in  the 
forcing  function  encountered  from  a representation  of  a helicopter  rotor  in 
forward  flight.  The  Runge-Kutta  self-starting,  averaging  methods  appear  more 
appropriate  for  this  application.  Enhanced  Runge-Kutta  techniques  that  require 
fewer  function  evaluations  and  allow  a variable  integration  interval  (Runge-Kutta- 
Felhberg)  with  no  loss  in  accuracy  or  stability  are  available.  Such  enhancements 
can  provide  a significant  increase  in  computational  efficiency. 

The  direct  numerical  integration  techniques  employed  in  practice  involve  either  ex- 
plicit or  implicit  formulations;  explicit  formulations  are  based  on  equilibrium 
conditions  at  the  previous  time  step,  whereas  implicit  formulations  are  based 
on  equilibrium  conditions  at  the  current  time  step.  The  central  difference 
method  is  an  example  of  an  explicit  method  while  the  Newmark-Beta,  Wilson- 
Theta,  and  Houbolt  methods  are  examples  of  implicit  methods. ^ The  differences 
between  explicit  and  implicit  methods  are  quite  important.  While  explicit  methods 

• typically  require  minimal  storage  and  are  computationally  efficient,  they  are 
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ANALYSIS,  Englewood  Cliffs,  New  Jersey,  Prentice-Hall,  hie. , 1976. 
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hampered  by  the  fact  that  their  stability  criteria  limit  the  step  sizes  that  can  be 
employed.  In  general,  these  step- size  limitations  are  related  to  the  highest  natu- 
ral frequency  of  the  system  of  equations  under  consideration.  The  implicit  meth- 
ods, on  the  other  hand,  offer  unconditional  stability  at  the  expense  of  increased 
storage  and  reduced  computational  efficiency.  However,  implicit  methods  are 
particularly  suitable  for  large  systems  of  equations  where  the  period  of  the  high- 
est natural  frequency  is  generally  not  known. 

Recently,  an  unconditionally  stable  explicit  algorithm  has  been  proposed  for  certain 

27 

structural  dynamics  problems.  Other  recent  publications  address  the  relative 

28 

stability  of  various  numerical  integration  techniques  for  vibration  problems  and 

29 

for  transient  rotor  dynamics  problems. 

2. 1.5.2  Coordinate  Systems  and  Transformations 

The  analysis  and  simulation  of  a complex  configuration  like  a helicopter  neces- 
sarily involve  the  use  of  a large  number  of  coordinate  systems  because  each 
of  the  aircraft  components  and  other  analysis  components  is  likely  to  have  at 
least  one  coordinate  system  associated  with  it.  Also,  in  many  cases,  coordi- 
nate systems  can  be  associated  with  individual  node  points  so  that  the  behavior 


Trujillo,  D.  M. , AN  UNCONDITIONALLY  STABLE  EXPLICIT  ALGORITHM  FOR 
STRUCTURAL  DYNAMICS,  International  Journal  for  Numerical  Methods  in 
Engineering,  Vol.  11,  1977,  pp.  1579-1592. 

®Wood,  W.  L. , ON  THE  ZIENKIEWICZ  FOUR-TIME-LEVEL  SCHEME  FOR  THE 
NUMERICAL  INTEGRATION  OF  VIBRATION  PROBLEMS,  International  Journal 
for  Numerical  Methods  in  Engineering,  Vol.  11,  1977,  pp,  1519-1528. 


Kaacak,  A.  F. , STABILITY  OF  NUMERICAL  INTEGRATION  TECHNIQUES  FOR 
TRANSIENT  ROTOR  DYNAMICS,  NASA  Technical  Paper  1092,  National  Aero- 
nautics and  Space  Administration,  November  1977. 


at  these  points  can  be  interpreted  in  a more  meaningful  manner.  Further, 
many  of  the  coordinate  systems  will  be  associated  with  rotating  components  such 
as  rotor  blades.  The  potential  use  of  such  a large  number  of  coordinate  sys- 
tems therefore  requires  that  a systematic,  convenient,  and  general  method  be 
used  for  computing  the  related  transformation  matrices  and  for  maintaining 
proper  relationships  among  the  various  coordinate  systems. 

Many  existing  helicopter  analysis  programs  employ  Euler  angles  for  locating 
coordinate  systems  and  for  defining  the  transformations  among  them.  This  method 
is  easy  to  use  and  comprehend,  but  has  the  disadvantage  that  the  transformations 
fail  at  certain  singularity  points.  Such  singularities  have  been  encountered,  for 
instance,  in  the  simulations  of  helicopter  looping  maneuvers. 

The  sensitivity  to  singularities  inherent  in  the  use  of  Euler  angles  can  be  elimi- 

30  31 

nated  by  the  use  of  quaternion  algebra,  ’ which  offers  a systematic,  general, 
and  powerful  method  for  handling  different  coordinate  systems.  It  has  also  been 
demonstrated  to  be  quite  cost-effective  for  this  purpose. 

For  this  reason,  all  internal  coordinate  systems  and  coordinate  transforma- 
tions will  be  based  on  the  use  of  quaternions;  however,  input  and  output  will 
be  in  terms  of  Euler  angles  with  which  helicopter  engineers  are  most  familiar. 

The  transformation  between  Euler  angles  and  quaternions  is  given  in  Appendix  E 
32 

of  Wertz. 
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Hamilton,  W.  R. , ON  A NEW  SPECIES  OF  IMAGINARY  QUANTITIES  CON- 
NECTED WITH  A THEORY  OF  QUATERNIONS,  Dublin  Proc. , Vol.  2,  No.  13, 
November  1843,  pp.  424-434. 

31Yang,  A.  T. , APPLICATION  OF  QUATERNION  ALGEBRA  AND  DUAL  NUMBERS 
TO  THE  ANALYSIS  OF  SPATIAL  MECHANISMS,  doctoral  dissertation,  Columbia 
University,  New  York,  1963. 
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2. 1.5.3  Stability  and  Control  and  Aeroelastic  Stability  Computations 

Both  the  stability  and  control  computations  and  the  aeroelastic  stability  computa- 
tions may  require  the  solution  of  complex  eigenvalue  problems.  In  addition,  the 
computation  of  natural  frequencies  requires  an  eigenvalue  solution.  Due  to  the 
advanced  state  of  technology  in  this  area  and  the  development  of  the  orthogonal 
reduction  (e.g. , Givens,  Householder)  and  iteration  methods  (e.g. , the  QR  algo- 
rithm), the  Project  team  does  not  anticipate  any  serious  problems  in  this  area. 

BHT  also  has  experience  with  Moving  Block  Fast  Fourier  Transform  and  Prony's 
Method  for  obtaining  aeroelastic  stability  data  from  time-history  records.  These 
methods  are  not  highly  reliable  at  this  time  and  must  be  used  with  some  care. 

Two  new  numerical  methods  for  dealing  with  the  stability  of  linear  systems  of 

33 

periodic  equations  have  recently  been  presented.  Based  on  the  use  of  multi- 

variable  Floquet-  Liapunov  theory,  these  methods  have  both  been  shown  to  be  the 

most  efficient,  general,  and  practical  numerical  methods  available  at  present. 

34 

Another  recent  numerical  contribution  in  the  area  of  stability  should  be  studied 
further  to  determine  its  potential  value  to  the  System. 

2. 1 . 5. 4 Solution  of  Trim  Equations 

A demanding  numerical  problem  occurs  when  solving  the  system  of  nonlinear 
algebraic  equations  that  represent  the  helicopter  trim  condition.  The  complexity 
of  the  problem  dictates  the  need  for  a successive  approximation  scheme  such 
as  the  Newton-Raphson  technique.  This  method,  however,  requires  initial 
starting  conditions  and  can  have  convergence  difficulties.  BHT  experience  with 

33 

Friedmann,  P. , Hammond,  C.  E. , and  Woo,  T.  H. , EFFICIENT  NUMERICAL 
TREATMENT  OF  PERIODIC  SYSTEMS  WITH  APPLICATION  TO  STABILITY 
PROBLEMS,  International  Journal  for  Numerical  Methods  in  Engineering. 

Vol.  11,  1977,  pp.  1117-1136. 

34Done,  G.  T.  S.,  and  Simpson,  A.,  DYNAMIC  INSTABILITY  OF  CERTAIN  CON- 
SERVATIVE AND  NON-CONSERVATIVE  SYSTEMS,  Journal  of  Mechanical  Engi- 
neering Science,  Vol.  19,  No.  6,  1977,  pp.  251-263. 
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the  multidimensional  Newton-Raphson  method  in  C81  has  shown  that  the  reliabil- 
ity of  the  technique  can  be  significantly  increased  when  it  is  augmented  with 
limiters  and  numerical  dampers.  BHT  believes  that  an  enhanced  Newton- 
Raphson  technique  can  be  made  to  work  efficiently  and  reliably  on  the  expanded 
systems  of  trim  equations  anticipated  in  the  future  for  the  System. 

2. 1. 5. 5 Interpolation  of  Input  Data 

Performance  analysis  of  aeronautical  systems  requires  specification  of  numer- 
ous functions  that  characterize  the  aerodynamic  coefficients  and  derivatives, 
inertial  characteristics,  propulsion  parameters,  and  other  subsystem  and  environ- 
mental effects.  Such  functions  are  frequently  dependent  on  several  Independent 
variables  and  are  stored  as  discrete  points  in  tables.  Interpolation  routines  must 
be  provided  in  the  software  to  extract  the  functional  information  from  the  tables. 
The  interpolation  routines  must  be  fast  because  the  tables  are  interpolated  many 
times,  must  be  reliable  because  key  computations  are  dependent  upon  interpolated 
’values,  and  must  be  flexible  because  the  function  being  interpolated  may  differ 
significantly  from  problem  to  problem.  Numerical  analysts  of  CSC  and  BHT  are 
acutely  aware  of  the  practical  considerations  of  tabular  interpolation.  CSC  has 
experience  in  developing  reliable  interpolators  for  aerodynamic  data  and  suggests 
odd-  and  low-  order  polynomial  interpolators  (e.g. , first  and  third  order)  capable 
of  interpolating  variable-interval  tabular  data  and  commencing  searches  of  tables 
from  the  points  bounding  the  previous  interpolated  value.  Odd-order  polynomials 
are  proposed  to  ensure  continuity  of  the  interpolated  function  when  the  interpola- 
tion span  consists  of  the  middle  portion  of  the  fitting  interval.  Continuity  is  en- 
sured because  switching  of  Interpolating  polynomials  occurs  at  data  points  that 
are  fit  exactly. 

2. 1.5. 6 Statistical  Analysis  and  Digital  Filtering 

Both  corporate  Project  team  members  have  extensive  experience  in  applying  fil- 
tering and  smoothing  techniques  such  as  finite-memory  digital  filters  (minimum 
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variance,  Kalman,  weighted  least- squares)  and  polynomial  smoothing  techniques 
to  experimental  data  for  aeronautical  systems.  The  team  is  also  aware  of  diffi- 
culties that  can  arise  due  to  low  signal-to-noise  ratio,  data  noise  (systematic  and 
random),  and  data  editing. 

2.1.6  Potential  of  the  System  Design  to  Accommodate  Advances  in  Helicopter 
Analysis  Technology 

The  inherent  modularity  and  adaptability  of  the  System  design  provide  the  growth 
potential  needed  to  add  innovative  analysis  concepts.  Based  on  the  history  of 
new  inventions,  it  is  expected  that  at  least  one  new  device,  concept,  or  material 
will  have  a strong  impact  on  the  helicopter  industry  during  the  15-year  cycle  of 
the  Long  Range  System,  similar  to  the  way  in  which  composite  materials  are 
having  several  effects  at  the  present  time.  The  use  of  such  unifying  and  sys- 
tematic concepts  as  the  finite  element  concept,  advanced  dynamic  coupling  methods, 
and  flexible  aerodynamic  models  allows  the  System  design  to  adapt  to  the  changing 
needs  of  the  future  without  changing  its  overall  structure,  thus  ensuring  a System 
that  can  be  maintained  and  extended  at  minimum  cost. 

One  example  of  a possible  future  device  is  an  electrostatic  autopilot  that  has 
been  used  on  fixed-wing  aircraft  but,  due  to  the  disturbance  of  the  electrostatic 

f 

field  by  the  rotor,  not  on  helicopters.  To  analyze  such  a device,  a description 

of  the  Earth's  basic  electrostatic  field  would  be  needed.  This  could  be  done  by 

using  software  elements  similar  to  those  that  describe  the  aerodynamic  field 

(see  Section  2. 1.4).  A rotor  electrostatic  formulation  could  then  be  defined  in 

a form  similar  to  the  rotor  wake  formulation  to  calculate  the  disturbance  caused  * 

by  the  rotor  to  the  electrostatic  field.  Another  software  element  would  be  the 

electrostatic  autopilot  itself,  which  would  make  control  motions  a function  of 
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the  electrostatic  potential  at  user-specified  node  points  in  a manner  very  sim- 
ilar to  the  automatic  flight  control  system  that  is  being  used  today. 

An  innovative  mechanical  device  might  provide  dynamic  coupling  between  any 
two  or  more  helicopter  components.  Acceleration  coupling  could  be  represented 
in  the  mass  matrix;  velocity  coupling,  in  the  damping  matrix;  and  displacement 
coupling,  in  the  stiffness  matrix.  Using  the  finite  element  technique,  unusual 
dynamic  couplings  may  be  achieved  and  their  effects  tested  and  examined  anal- 
ytically rather  than  by  actually  building  the  hardware.  The  analysis  of  the 
effects  of  such  an  innovative  device  would  require  only  the  addition  of  a few 
new  software  elements  to  represent  the  device. 

Also,  any  device  that  changes  the  aerodynamic  field  or  modifies  the  aerodynamic 
coupling  between  the  aircraft  components  can  be  accounted  for  by  the  use  of  one 
or  the  other  of  the  two  types  of  aerodynamic  models  discussed  in  Section  2. 1.4. 
Though  some  new  software  elements  would  have  to  be  defined,  the  two  basic 
types  of  aerodynamic  models  would  remain  unchanged. 

Although  not  required  by  the  Baseline  Type  A System  Specification,  the  use  of 
the  System  for  optimization  studies  represents  yet  another  area  of  potential 
growth.  By  using  appropriate  optimization  algorithms,  the  System  could  be 
adapted  for  such  needs.  The  design  of  an  aircraft  with  maximum  endurance  or 
range,  the  synthesis  of  a particular  aircraft  component  with  natural  frequencies 
that  are  designed  to  avoid  resonances  with  some  other  components,  and  optimi- 
zation of  rotor  planform  and  twist  in  preliminary  design  are  examples  of  such 
optimization  applications. 

The  design  of  the  System  makes  it  possible  to  investigate  analysis  problems  such 
as  those  mentioned  above  as  well  as  other  analysis  problems  by  enhancing  its 

capabilities.  This  may  be  done  without  changing  the  basic  structure  of  the  System 
and  at  minimum  cost. 
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2.2  SYSTEM  HIERARCHY 


> t 

! Because  of  the  complexity  of  the  functional  requirements  placed  on  the  System, 

I the  System  itself  is  complex,  i.e. , composed  of  many  elements.  This  section 

i 

I defines  the  terms  used  to  describe  the  System's  elements  which  are  presented  in 

I 

i a top-down  hierarchical  fashion. 

I The  System  is  made  up  of  a set  of  modules.  Because  a module,  which  is  the 

¥ 

¥ 

equivalent  of  a FORTRAN  subprogram,  is  a relatively  small  part  of  the  System  t 

I 

I (a  module  consists  of  on  the  order  of  100  executable,  high-level  language  source 

statements),  it  is  convenient  in  describing  the  architecture  of  the  System  to  give 
names  to  particular  sets  of  modules  in  the  System.  The  names  used  are  complex, 
subsystem,  package,  and  subpackage.  These  sets  of  modules  are,  in  the  termi- 
nology of  set  theory,  subsets  of  the  System.  The  terms  complex,  subsystem, 
package,  subpackage,  and  module  are  defined  below  and  summarized  in  the  Glos- 
sary for  reference. 

The  System  is  made  up  of  two  complexes:  the  Operational  Complex  and  the  Sup- 
port Complex.  The  Operational  Complex  is  that  subset  of  modules  of  the  System 
used  to  obtain  predictions  in  the  five  areas  of  helicopter  analysis  previously  enu- 
merated. The  Support  Complex  is  that  subset  of  modules  of  the  System  needed  to 
support  the  development,  test,  configuration  management,  and  documentation  of 

the  Operational  Complex  and  to  support  the  overall  management  of  the  System. 

' 

The  two  complexes  are  mutually  exclusive  and  exhaustive;  i.  e. , a module  of  the 
System  is  an  element  of  the  Operational  Complex  or  of  the  Support  Complex  but 
not  an  element  of  both,  and  every  module  of  the  System  is  an  element  of  one  of 
the  complexes. 

Each  complex  is  made  up  of  subsystems.  A subsystem  is  a set  of  modules  that  « 

performs  a related  aggregate  of  System  functions.  For  example,  one  subsystem  of 
the  Operational  Complex  is  the  Trim  Solution  Subsystem,  which  consists  of  all  the 
modules  that  are  used  to  find  a steady- state  solution  to  the  set  of  equations 
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represented  by  the  simulation  model.  A subsystem  is  not  an  executable  entity. 

Subsystems  are  defined  for  the  purpose  of  relating  the  software  design  of  the  t 

System  to  the  requirements  of  the  Type  A System  Specification;  aiding  the  presen- 
tation of  a logical,  top-down  design;  and  aiding  in  configuration  management. 

Every  module  of  the  System  belongs  to  one  and  only  one  subsystem.  In  the  Opera- 
tional Complex,  a subsystem  is  characterized  as  being  a technology  subsystem  or 
an  executive  subsystem.  The  collection  of  technology  subsystems  is  called  the 
Technology  Component,  and  the  collection  of  executive  subsystems  is  called  the 
Executive  Component.  The  Technology  Component  provides  all  the  functions  of 
helicopter  and  associated  mathematical  analyses.  The  Executive  Component  pro- 
vides the  functions  of  user  interface,  run-time  management,  data  base  manage- 
ment, and  operating  system  interface.  These  two  components  are  mutually 
exclusive  and  exhaustive,  i.e. , a module  in  the  Operational  Complex  is  in  only 
one  component.  Figure  3 shows  the  major  subdivisions  of  the  hierarchy  of  the 
System:  the  two  complexes  and  the  two  components  of  the  Operational  Complex. 

Each  subsystem  of  the  System  is  made  up  of  packages.  A package  is  a set  of  mod- 
ules that  performs  a related  aggregate  of  functions  of  the  subsystem  to  which  it 
belongs.  Every  module  of  the  System  belongs  to  only  one  package.  Large  pack- 
ages are  frequently  composed  of  subpackages;  a subpackage  is  a subset  of  a 
package  and  is  discussed  below.  Execution  of  the  packages  and  subpackages  of 
the  Technology  Component  is  controlled  by  the  Run-Time  Control  Package  of  the 

* r 

Executive  Component.  Packages  and  subpackages  may  be  Invoked  either  as  a , 

result  of  entries  in  the  Sequence  Control  Table,  which  is  constructed  from  user- 

specified  data  by  the  Executive  Component  during  the  input  phase  of  an  analysis 

run,  or  as  a result  of  requests  from  a module  of  the  Technology  Component 

during  the  processing  phase  of  an  analysis  run. 

Each  package  may  be  made  up  of  subpackages.  A subpackage  is  a set  of  modules 
that  performs  a related  aggregate  of  functions  of  the  package  to  which  it  belongs. 

Often  when  discussing  elements  of  the  software  system  hierarchy,  one  wishes 
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Figure  3.  Major  Subdivisions  of  the  Software  System  Hierarchy 


to  refer  to  a collection  of  modules  that  are  packages  or  subpackages,  but  the  con- 
text calls  for  a reference  to  an  inspecific  level  of  the  System  hierarchy.  The  term 
software  element  is  used  to  denote  such  a collection  of  modules.  Because  a pack- 
age or  subpackage  may  in  certain  limited  instances  consist  of  only  one  module,  a 
software  element  can  denote  a module.  A module,  the  basic  element  of  the  System, 
has  the  following  principal  characteristics: 

• It  performs  only  one  function. 

• It  has  a unique  name. 

• It  constitutes  one  compilation  or  assembly. 

• An  invocable,  executable  module  consists  of  no  more  than  100  execut- 
able statements.  (Not  all  modules  are  executable,  e.g. , a FORTRAN 
block  data  subprogram.) 

• It  has  only  one  point  of  entry. 

Figure  4 shows  the  hierarchy  of  subsystem,  package,  subpackage,  and  module. 

The  hierarchy  of  the  entire  System  is  obtained  by  placing  Figure  4 under  the  Tech- 
nology Component,  the  Executive  Component,  and  the  Support  Complex  of  Fig- 
ure 3.  Rectangles  at  the  subsystem,  package,  and  subpackage  levels  denote  a set 
of  modules.  A rectangle  at  this  level  does  not  denote  a module  driver,  nor  is  the 
execution  sequence  of  the  software  implied  in  any  way  by  the  hierarchy  diagrams 
(they  are  not  "who  calls  who"  hierarchy  diagrams).  In  addition,  the  order  in  which 
the  rectangles  are  placed  from  left  to  right  at  any  level  is  quite  arbitrary:  no  exe- 
cution order  or  sequencing  is  implied. 

2.3  OPERATIONAL  COMPLEX 

The  Operational  Complex  consists  of  the  Technology  Component  and  the  Executive 
Component.  The  Technology  Component  is  made  up  of  10  subsystems,  as  described 
in  Section  2.3. 1.  The  order  of  execution  of  the  software  elements  required  to 
analyze  a helicopter  model  and  the  data  used  during  an  analysis  are  specified  by 
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the  Sequence  Control  Table,  which  is  constructed  by  the  User  Input  Package  (a 
package  of  the  Executive  Component)  from  user  input  for  an  analysis  run. 

Communication  between  and  among  the  software  elements  listed  in  the  Sequence 
Control  Table  is  accomplished  by  allowing  a software  element  to  use  input  data 
that  were  calculated  by  another  software  element  earlier  in  the  execution  se- 
quence. Technology  Component  software  elements  have  the  capability  to  affect 
the  execution  sequence  dynamically  by  defining  a System  Command  to  be  executed 
immediately  by  the  Executive  Component.  Thus,  a software  element  is  able  to 
issue  a command  causing  the  Executive  Component  to  execute  a second  software 
element  or  select  additional  data  from  the  Run  Data  Base.  Upon  completion  of  the 
System  Command  execution,  the  software  element  issuing  the  command  continues 
to  operate  from  the  point  immediately  following  the  point  at  which  the  command 
was  issued. 

The  Executive  Component  satisfies  the  secondary  and  implied  functional  require- 
ments necessary  for  a user-oriented,  transportable,  easily  extendable  software 
system  for  comprehensive  analyses  of  helicopters.  The  Executive  Component 
consists  of  four  subsystems,  as  described  in  Section  2,3.2:  the  User  Interface 
Subsystem,  the  Run-Time  Management  Subsystem,  the  .Data  Base  Management 
Subsystem,  and  the  Operating  System  Service  Subsystem. 

The  general  flow  in  the  Operational  Complex  of  the  System  is  shown  in  Figure  5. 

The  System  operates  in  three  phases  in  performing  an  analysis  run:  the  input 
phase,  the  processing  phase,  and  the  output  phase. 

During  the  input  phase,  the  user  input  is  read  and  interpreted  by  the  User  Input 
Package  of  the  User  Interface  Subsystem  of  the  Executive  Component.  Also  input 
to  this  phase  are  the  Master  Command  File,  the  Master  Data  Base  and,  optionally, 
a Restart  File. 

The  Master  Command  File  contains  standard  System  Command  subsequences.  The 
User  Input  Package  selects  subsequences  based  on  information  in  user  input  and 
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Figure  5.  Control  and  Data  Flow  for  the  Operational  Complex 
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constructs  from  these  data  the  sequence  of  System  Commands  for  the  analysis  run. 

This  sequence  is  stored  in  internal  form  in  the  Sequence  Control  Table.  The  Mas- 

I 

ter  Data  Base  contains  previously  stored  descriptions  of  standard  aircraft  com- 
ponents and  other  analysis  components;  maneuvers,  conditions,  and  operating 
regimes;  and  failure/damage  effects.  The  User  Input  Package  selects  and  modi- 
fies data  from  the  Master  Data  Base  based  on  information  in  user  input  and  con- 
structs a Run  Data  Base  for  an  analysis  run.  The  Sequence  Control  Table  defines 
the  sequence  of  Technology  Component  software  elements  and  supporting  Executive 
Component  software  elements  to  be  executed  in  response  to  the  user  input.  The 

Run  Data  Base  contains  all  data  necessary  for  input  to  the  Technology  Component  ' 

software  elements  in  the  sequence.  Section  2.  5 provides  data  flow  diagrams  de- 
scribing examples  of  the  processing  flow  and  data  flow  of  the  sequences  and  subse- 
quences of  System  Commands  in  the  Master  Command  File. 

The  Restart  File  is  a file  that  was  produced  as  a Checkpoint  File  in  an  earlier 
analysis  run.  It  contains  the  results  produced  at  intermediate  points  in  the  earlier 
run.  The  User  Input  Package  uses  the  Restart  File,  the  Master  Data  Base,  and 
the  Master  Command  File,  as  specified  by  user  input,  to  establish  a Run  Data 
Base  and  a Sequence  Control  Table.  This  capability  allows  a user  to  continue  an 

analysis  without  repeating  calculations  already  performed  in  an  earlier  analysis  ,, 

run. 

During  the  processing  phase,  the  Sequence  Control  Package  of  the  Run-Time  Man- 
agement Subsystem  of  the  Executive  Component  controls  the  sequence  of  technology 
and  executive  software  elements  to  be  executed  as  defined  in  the  Sequence  Control 
Table.  Before  and  after  each  software  element  is  executed,  the  Run-Time  Con- 
trol Package  (of  the  Run-Time  Management  Subsystem)  is  executed  to  perform 
housekeeping  functions  necessary  to  make  input  data  accessible  to  the  software 
element  and  to  provide  for  disposition  of  its  output  data.  One  software  element 
that  will  be  executed  when  specified  by  System  Command  is  the  Checkpoint  Pack- 
age. The  Checkpoint  Package  saves  intermediate  results  from  the  Run  Data  Base 
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on  the  Checkpoint  File  as  shown  in  Figure  5.  The  Checkpoint  File  may  then  be 
used  as  a Restart  File  in  a subsequent  analysis  run  to  avoid  any  repetition  of  al- 
ready completed  calculations.  The  Sequence  Control  Package  continues  to  process 
the  entries  of  the  Sequence  Control  Table  until  the  last  table  entry  has  been  satis- 
fied. 

During  the  output  phase,  all  data  that  have  been  output  by  the  software  elements  of 
the  Technology  Component  are  printed,  plotted,  displayed,  or  recorded  on  mag- 
netic tape  or  into  a saved  output  data  file  for  future  use  by  the  User  Output  Pack- 
age according  to  directives  in  the  Sequence  Control  Table.  It  should  be  noted  that 
output  processing  may  take  place  either  after  the  execution  of  a specific  Technol- 
ogy Component  software  element  or  after  the  completion  of  the  sequence  of  opera- 
tions for  a given  analysis  run. 

The  remainder  of  this  section  provides  a more  detailed  discussion  of  the  Technol- 
ogy and  Executive  Components.  For  each  subsystem,  the  packages  of  the  subsys- 
tem are  shown  on  a hierarchy  diagram,  with  each  package  named  in  a rectangle. 
The  function  performed  by  the  package  is  given  below  the  rectangle. 

2. 3. 1 Technology  Component 

The  Technology  Component  is  that  part  of  the  System  which  defines  the  mathemati- 
cal analysis  for  the  entire  simulation.  This  includes  all  of  the  components  and 
couplings  described  in  Section  3.2.2  of  the  Baseline  Type  A System  Specification. 
This  specification  presents  several  general  classes  of  problems  which  range  from 
simple  to  very  complex. 

The  design  of  the  Technology  Component  was  accomplished  by  dividing  the  System 
into  major  functions  and  then  subdividing  these  functions  to  achieve  a true  top-down 
structure.  The  major  functions  are  identified  with  10  subsystems  as  shown  in 
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Figure  6.  No  functional  overlap  exists  between  or  among  subsystems.  The  10 
technology  subsystems  are 

1.  Simulation  Model  Initialization  Subsystem 

2.  Simulation  Model  Subsystem 

3.  Trim  Solution  Subsystem 

4.  Maneuver  Subsystem 

5.  Stability  and  Control  Subsystem 

6.  Acoustics  Subsystem 

7.  Aeroelastic  Stability  Subsystem 

8.  General  Mathematical  Operations  Subsystem 

9.  External  Models  Interface  Subsystem 

10.  Accuracy  Assessment  Subsystem 

Although  10  subsystems  are  currently  defined,  the  design  of  the  Technology  Com- 
ponent is  not  rigid;  if  a new  capability  is  defined  in  the  Type  A System  Specifica- 
tion, either  it  is  allocated  to  an  existing  subsystem  or  a new  subsystem  is  defined 
to  accommodate  it.  Subsystems  are  defined  principally  for  management  control 
and  for  unity  and  ease  of  documentation;  because  of  the  ability  of  the  Executive 
Component  to  recognize  software  elements  independent  of  affiliation  with  a partic- 
ular subsystem,  subsystems  may  be  added,  deleted,  or  reorganized  completely 
without  affecting  the  operation  of  the  System. 

Because  the  System  must  meet  the  Government’s  long-range  objectives,  the  design 
of  the  Technology  Component  must  initially  be  formulated  around  the  solution  of 
the  most  complex  problem.  A way  must  then  be  found  to  simplify  the  formulation 
so  that  the  solution  of  simple  problems  is  not  penalized  by  high  overhead  costs. 
The  mathematical  formulation  selected  is  discussed  in  Section  2. 1.  The  form  of 
the  equations  is  a set  of  differential  equations  in  time  represented  by  mass,  damp- 
ing, and  stiffness  matrices.  The  solution  variables  of  these  equations  are  called 
the  analysis  degrees  of  freedom. 
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The  first  two  subsystems  shown  in  Figure  6,  the  Simulation  Model  Initialization 
Subsystem  and  the  Simulation  Model  Subsystem,  are  used  to  establish  and  generate 
the  mass,  damping,  and  stiffness  matrices  and  the  vector  of  forcing  functions. 

The  Simulation  Model  Initialization  Subsystem  establishes  coordinate  systems, 
sets  internal  indexes  to  indicate  how  matrices  are  partitioned,  and  initializes  con- 
stant coefficients.  The  software  elements  of  the  Simulation  Model  Subsystem  per- 
form the  actual  calculations  necessary  to  generate  elements  of  the  mass,  damping, 
and  stiffness  matrices  and  the  vector  of  forcing  functions.  The  software  elements 
of  this  subsystem  are  generally  executed  many  times  during  the  processing  of  a 
problem  and  are  invoked  by  modules  in  several  other  subsystems. 

The  next  five  subsystems  in  Figure  6 are  directly  related  to  five  types  of  solutions 
of  the  equations  of  motion: 

• The  Trim  Solution  Subsystem  contains  those  packages  that  find  a 
steadyr- state  solution  for  the  simulation  model.  This  solution  of  the 
steady-state  problem  is  completed  prior  to  calculating  any  of  the  air- 
craft technical  characteristics  and  is  frequently  an  end  in  itself. 

• The  packages  of  the  Maneuver  Subsystem  are  used  during  a direct 
timewise  integration  of  the  equations  of  motion.  A number  of  external 
disturbances  to  the  steady-state  condition  may  be  introduced  by  pack- 
ages of  the  Maneuver  Subsystem.  These  include  prescribed  or  auto- 
mated control  motions,  gust  disturbances,  and  others,  which  are 
described  later. 

• The  packages  of  the  Stability  and  Control  Subsystem  calculate  frequen- 
cies and  damping  coefficients  for  the  response  of  the  rigid-body  motion 
of  the  airframe.  After  performing  these  calculations,  linear  transfer 
functions  and  airframe  rigid- body  frequency  response  may  be  computed. 

• The  packages  of  the  Acoustics  Subsystem  use  aerodynamic  and  rotor 
wake  data  obtained  during  the  other  processes  to  calculate  the  sound 
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level  generated  by  the  rotors  and  other  components.  Factors  of  envi- 
ronment, insulation,  and  dissipation  are  then  used  to  calculate  the 
sound  level  throughout  a field  of  interest. 

• The  packages  of  the  Aeroelastic  Stability  Subsystem  calculate  frequen- 
cies and  damping  coefficients  for  the  aeroelastic  rotor/airframe.  The 
packages  of  this  subsystem  use  one  of  several  methods  to  find  the  fre- 
quencies and  damping  of  the  coupled  aeroelastic  system. 

The  eighth  subsystem  of  the  Technology  Component,  the  General  Mathematical 
Operations  Subsystem,  contains  packages  of  a general  mathematical  nature,  such 
as  differential  equation  solution,  eigenvalue  solution,  and  interpolation.  The  pack- 
ages in  this  subsystem  are  used  by  software  elements  of  other  subsystems  of  the 
Technology  Component  and  may  be  called  by  the  Run-Time  Control  Package  of  the 
Executive  Component  during  the  execution  of  an  analysis  run. 

The  ninth  subsystem  of  the  Technology  Component  is  the  External  Models  Interface 
Subsystem.  Each  package  of  this  subsystem  calculates  the  output  required  for  one 
external  model.  This  subsystem  generates  whatever  data  an  external  model  needs 
before  control  is  returned  to  the  Executive  Component  for  actual  output. 
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The  final  subsystem  of  the  Technology  Component  is  the  Accuracy  Assessment  Sub- 
system. This  subsystem  calculates  the  sensitivity  factors,  standard  deviations, 
and  expected  value  ranges  for  each  of  the  variables  for  which  the  user  has  re- 
quested accuracy  assessment  data. 

Sections  2. 3. 1. 1 through  2. 3. 1. 10  present  more  detailed  discussions  of  the 
10  Technology  Component  subsystems.  As  indicated  in  Section  2.2,  each  subsys- 
tem is  divided  into  packages.  Packages  in  most  cases  are  further  subdivided  into 
subpackages.  Subpackages  and  their  functions  are  discussed  in  Section  3,  System  ( 

Capability.  To  facilitate  the  discussion  of  the  subsystems,  a hierarchy  diagram 
showing  the  packages  of  each  subsystem  is  presented.  Each  rectangle  of  the 


I * 
| 


80 


hierarchy  diagram  defines  the  package  name,  and  below  the  rectangle  the  function 
of  the  package  appears. 

2.3. 1. 1 Simulation  Model  Initialization  Subsystem 

The  packages  of  the  Simulation  Model  Initialization  Subsystem  perform  initializa- 
tion functions  for  constants  and  aircraft  component  models  that  will  be  used  by 
packages  of  the  Simulation  Model  Subsystem.  The  manner  in  which  the  subsystem 
is  divided  into  packages  is  shown  in  the  hierarchy  diagram  for  the  subsystem  (Fig- 
ure 7).  Eight  packages  have  been  identified  to  perform  initialization  and  input  data 
checking  functions.  The  analysis  definition  input  data  for  the  simulation  includes 
a description  of  both  the  aircraft  and  its  environment.  The  aircraft  description  is 
related  to  the  geometry  and  structural  properties  of  the  aircraft  itself.  The  envi- 
ronment description  concerns  such  analysis  components  as  airmass,  wind  tunnel, 
test  stand,  and  ground/deck.  The  principal  subsystem  output  is  the  simulation 
data  used  during  the  problem  solution. 

The  Combine  Aircraft  Components  Package  performs  initialization  functions  for 
the  parts  of  the  simulation  that  describe  the  aircraft.  These  functions  include 
reasonability  analysis  of  the  input  data  describing  the  aircraft,  initial  estimates 
of  solution  values,  and  calculations  of  constant  coefficients  for  the  rotor,  air- 
frame, engine/drive  system,  and  control  system/pilot  models.  The  aircraft 
model  data  that  it  generates  are  later  used  by  the  Combine  Aircraft  and  Environ- 
ment Components  Package. 

The  Combine  Environment  Components  Package  performs  initialization  functions 
for  the  parts  of  the  simulation  comprising  the  aircraft  environment,  including  rea- 
sonability analysis  of  input  data  and  the  setup  of  the  airmass  and  ground/deck 
models. 

The  aircraft  and  environment  models  are  combined  and  verified  by  the  Combine 
Aircraft  and  Environment  Components  Package.  A reasonability  analysis  verifies 
the  compatibility  of  the  aircraft  and  environment  models  used  in  the  simulation. 
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This  package  also  produces  data  elements  in  a form  ready  for  use  by  the  Simula-  ] 

I 

tion  Model  Subsystem. 

The  Coordinate  Systems  and  Transformations  Package  establishes  the  number  of 

I 

different  coordinate  systems  required,  their  initial  locations,  their  initial  orienta-  1 

tions,  and  their  interrelationships. 

The  Rotor  Finite  Element  Initialization  Package  calculates  the  mass,  damping, 
and  stiffness  matrices  for  a finite  element  rotor  analysis.  This  analysis  includes 
the  capability  to  model  redundant  load  paths. 

The  Rotor  Modes  Package  computes  structural  natural  frequencies  and  normalized 
mode  shapes  for  the  rotor.  The  frequency  and  mode  shape  data  that  are  computed 
may  be  used  in  a subsequent  simulation  analysis,  or  they  may  be  the  primary  en- 
gineering output  required  for  a particular  case. 

The  Wake  Initialization  Package  is  provided  to  initialize  the  particular  wake  model 
to  be  used  in  a simulation.  Algorithms  are  provided  to  compute  initial  estimates 
of  the  rotor  wake  geometry  and  wake  element  influence  coefficients  based  on  user 
input. 

The  Derived  Aircraft  Properties  Package,  which  has  been  allocated  to  the  Long 
Range  System,  is  planned  to  provide  several  different  methods  of  generating  air- 
craft properties  from  user  input.  In  the  final  System  design,  these  different 
methods  may  be  provided  as  separate  packages.  This  is  one  area  in  which  System 
growth  is  expected  for  the  Long  Range  System. 

2.3. 1.2  Simulation  Model  Subsystem 

The  Simulation  Model  Subsystem  consists  of  the  software  elements  that  represent 
the  physical  character  of  the  configuration.  It  is  composed  of  seven  packages,  as 
shown  in  the  hierarchy  diagram  for  the  subsystem  (Figure  8).  A distinction  has 
been  made  between  packages  that  model  portions  of  the  aircraft  and  those  that 


model  the  environment.  This  is  a convenient  distinction  for  the  purpose  of  data 
input  and  representation  of  airframe  couplings  and  interactions. 

Packages  of  the  subsystem  use  simulation  input  and  flight  conditions  data  generated 
by  software  elements  of  the  Simulation  Model  Initialization  Subsystem  to  produce 
(1)  forcing  functions  and  coupling  coefficients  for  the  equations  of  motion  and  (2) 
distributed  aerodynamic  loads  and  vibrations  data  and  the  aerodynamic  forces  and 
moments  on  each  aircraft  component.  Only  those  packages  and  subpackages  needed 
for  analyzing  the  user's  problem  are  executed  during  the  analysis. 

The  Rotor  Package  consists  of  the  subpackages  required  to  model  the  dynamic  be- 
havior of  a rotor.  The  subpackages  range  in  level  of  complexity  from  a rotor  map 
table  look-up  to  complete  detailed  aeroelastic  rotor  analyses.  The  indicated 
methods  generally  have  different  levels  of  complexity.  For  example,  the  rigid- 
blade  analysis  has  one  or  two  degrees  of  freedom  for  each  blade.  In  contrast,  the 
advanced  rotor  models  use  many  node  points  and  analysis  degrees  of  freedom  for 
each  blade. 

The  Control  System/Pilot  Package  includes  the  aircraft  components  required  to 
represent  the  helicopter  control  system  and  pilot  in  a simulation.  Subpackages 
either  take  the  form  of  complete  models  of  control  systems  for  specific  helicopter 
types  (e.g. , single-rotor,  tandem-rotor,  tilt-rotor)  or  are  models  of  control  sys- 
tem components  (e.g. , mixing  boxes,  actuators).  Models  in  the  latter  category 
may  be  coupled  to  form  specific  control  system  models. 

The  characteristics  of  engines  and  drive  systems  are  represented  by  the  Engine/ 
Drive  System  Package.  Performance  and  dynamic  response  characteristics  of 
various  engine  types  (e.g. , reciprocating  and  turbine)  are  modeled.  Both  mechan- 
ical and  gas-cycle  drive  systems  are  represented.  Drive  system  subpackages  for 
flexible  and  dynamic  analyses  either  take  the  form  of  complete  drive  system 
models  or  are  models  of  components  (e.g. , drive  shafts,  couplings,  gearboxes). 
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The  Airframe  Package  includes  the  basic  fuselage  and  a number  of  appendages, 

such  as  rotor  pylons,  aerodynamic  surfaces,  landing  gear,  and  external  stores.  i 

The  pylon  model  is  general  in  nature  so  that  it  can  also  be  used  to  represent  the 
wing  of  a tilt-rotor  aircraft. 

The  Airmass  Package  consists  of  subpackages  that  compute  the  location,  effects, 
and  interactions  of  the  rotor  and  wing  wakes  and  evaluate  both  steady  and  unsteady 
aerodynamic  forces.  Separate  subpackages  are  identified  for  calculation  of  aero- 
dynamic coefficients  so  that  they  may  easily  be  replaced  or  upgraded  as  better 
aerodynamic  analyses  are  developed.  The  simplest  inflow  model  is  the  inclined 
rotor  disk  momentum  theory  model.  This  model  predicts  a uniform  downwash 
field  on  the  rotor  disk  with  a superimposed  moment  of  momentum  component  to 
give  some  accounting  for  the  azimuthal  variation  in  blade  loading.  The  more  com- 
plex class  of  flow  field  model  is  the  free-wake  vortex  element  model.  Aerody- 
namic flow  fields  for  bodies  and  surfaces  are  calculated  using  aerodynamic  panel 
methods . 

The  Ground/Deck  Surface  Package  provides  for  the  aerodynamic  effects  of  a 
ground  plane,  a ship  deck,  or  wind  tunnel  walls.  Representations  of  the  dynamic 
effects  of  fixed,  moving,  slanted,  bumpy,  or  elastic  ground  planes  are  included 
for  use  in  taxi,  takeoff,  and  landing  studies.  A liquid-surface  model  is  imple- 
mented as  a free-surface  representation.  Some  of  these  items  are  beyond  the 
present  state  of  the  art,  however,  and  will  require  additional  research  work  to  im- 
plement. ‘ 

The  final  package  of  the  Simulation  Model  Subsystem  is  the  Structural  Coupling 
Package.  This  package  provides  the  capability  to  couple  the  structural  components 
that  make  up  the  configuration.  The  uncoupled  mass,  damping,  and  stiffness  mat- 

t 

rices  and  forcing  vectors  are  transformed  into  the  coupled  equations  for  the  en- 
tire configuration.  The  Structural  Coupling  Package  also  calculates  the  global 
acceleration  vector  for  the  entire  configuration  and  derives  from  it  the  local 
acceleration  vectors  for  each  component. 
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2. 3. 1. 3 Trim  Solution  Subsystem 


The  Trim  Solution  Subsystem  is  used  to  find  a steady-state  solution  to  the  set  of 
equations  represented  by  the  simulation  model.  This  process  is  one  of  finding  a 
set  of  values  for  the  user-specified  trim  variables  that  allows  the  aircraft  to  con- 
tinue the  same  flight  path  indefinitely  if  not  disturbed.  Three  different  approaches 
to  the  problem  are  shown  in  the  hierarchy  diagram  for  the  subsystem  (Figure  9). 

The  Fly-to-Trim  Package  performs  a simulation  of  a specialized  type  of  maneu- 
ver. This  maneuver  would  be  used  to  find  a steady-state  condition  that  satisfies 
a user-selected  set  of  goals,  as  defined  in  Section  3. 2. 2. 1. 6.  a of  the  Baseline 
Type  A System  Specification.  Both  the  generation  of  a suitable  autopilot  to  seek 
the  trim  condition  and  the  choice  of  an  appropriate  convergence  test  to  verify  a 
trim  condition  when  found  are  engineering  problems  that  require  further  analysis 
to  make  this  method  economical. 

Both  of  the  iterate-to-trim  packages  contain  procedures  to  set  up  and  solve  a set 
of  nonlinear  algebraic  equations  for  the  steady-state  solution  of  the  equations  of 
motion.  These  procedures  could  have  problems  with  convergence  not  encountered 
by  the  fly-to-trim  method.  The  Decoupled  Ite rate -to-T rim  Package  divides  the 
equations  of  motion  into  user-specified  groups  and  converges  each  group  sepa- 
rately in  cycles  to  find  the  solution.  In  some  cases  this  eliminates  convergence 
problems  experienced  with  the  Simultaneous  Iterate- to- Trim  Package. 

Input  and  output  for  all  packages  are  identical.  Input  consists  of  simulation  input 
data  with  coordinate  systems  and  transformations  in  addition  to  the  specification 
of  the  desired  trim  condition.  When  the  trim  condition  is  found,  output  includes 
the  steady-state  performance  data,  steady-state  loads  data  (if  requested),  and  the 
flight  condition  data  with  the  trim  variables  determined. 


Figure  9.  Hierarchical  Definition  of  the  Trim 
Solution  Subsystem 
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2. 3. 1.4  Maneuver  Subsystem 

The  packages  of  the  Maneuver  Subsystem  simulate  all  specified  types  of  maneu-  1 

vers  or  transient  flight  conditions.  The  maneuvers  may  include  prescribed  con- 
trol motions,  gust  disturbances,  landings,  the  following  of  a specified  flight  path, 
component  failure,  aircraft  damage,  or  other  options,  as  described  in  para- 
graphs b,  c,  and  d of  Section  3. 2. 2. 1.6  and  in  Section  3. 2. 2. 1.7  of  the  Baseline 
Type  A System  Specification.  Figure  10  shows  that  the  subsystem  is  divided  into 
four  packages. 

The  Prescribed  Control  Motions  Package  converts  the  user's  input  for  control  mo- 
tions into  functions  of  time  for  control  positions.  The  controls  which  may  be 
moved  include  all  of  the  primary  and  secondary  controls. 

The  Prescribed  Aircraft  Response  Package  calculates  motions  of  the  primary  con- 
trols during  a time-history  solution  to  attempt  to  achieve  a user-specified  response 
of  some  aircraft  motion.  The  most  common  example  of  this  function  is  the  follow- 
ing of  a prescribed  time  history  of  vertical  load  factor  without  excessive  rolling 
or  yawing  motions. 

All  types  of  airflow  disturbances  are  calculated  by  the  Gust  Response  Package. 

This  package  calculates  the  disturbance  in  the  fluid  flow  field  as  a result  of  gusts, 
trailing  vortices,  or  weapons  blast.  The  effects  are  calculated  at  every  aerody- 
namic node  point  of  the  configuration. 

j \ 

The  Initiate  Failure/Damage  Effects  Package  activates  the  failure  or  damage  ef- 
fects for  which  the  user  has  made  provision.  These  may  be  activated  at  a certain 
time  or  by  the  Impact  of  two  components  such  as  a rotor  and  fuselage.  The  repre- 
sentation of  the  damage  itself  is  accomplished  in  the  subpackages  of  the  Simulation 
Model  Subsystem. 
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2.3. 1.5  Stability  and  Control  Subsystem 

The  packages  of  the  Stability  and  Control  Subsystem  evaluate  the  specialized  data 
required  for  the  stability  and  control  part  of  helicopter  analysis.  The  subsystem 
is  divided  into  three  packages,  as  shown  in  the  hierarchy  diagram  (Figure  11). 

These  three  packages  constitute  a sequence  of  processes  used  to  produce  the 
stability  and  control  data.  These  data  are  the  stability  eigenvalues  and  eigenvec- 
tors, transfer  functions,  and  frequency  responses.  The  stability  derivatives  may 
also  be  useful  engineering  output. 

The  Linearize  Equations  for  Stability  and  Control  Package  first  calculates  deriva- 
tives of  aircraft  forces  and  moments  with  respect  to  control  positions,  attitudes, 
and  velocities.  These  numerically  calculated  stability  derivatives  aid  the 
stability-and-control  engineer  in  improving  handling  qualities  by  indicating  where 
the  design  should  be  changed.  The  package  then  generates  a set  of  linear  differ- 
ential equations  in  mass,  damping,  and  stiffness  matrix  form.  The  elements  of 
the  mass  matrix  are  obtained  directly  from  the  simulation  model,  and  the  elements 
of  the  damping  and  stiffness  matrices  are  obtained  from  the  stability  derivatives 
previously  calculated.  The  control  forcing  vectors  for  the  forced  response  calcu- 
lations also  use  the  stability  derivatives. 

The  Stability  Eigenvalues  and  Eigenvectors  Package  calculates  the  actual  stability 
eigenvalues  for  the  aircraft  with  the  controls  fixed  and  calculates  the  degree  of 

control  that  can  be  achieved  when  the  controls  are  moved.  _ 

The  Transfer  Functions  and  Frequency  Response  Package  makes  use  of  the  stabil-  \ 

ity  eigenvalues  and  eigenvectors  data.  The  transfer  functions  are  really  an  ex- 
pression of  the  combined  stability  roots  in  fractional  form  to  give  the  response  of 
some  aircraft  degree  of  freedom  to  a movement  of  one  of  the  controls.  The  fre- 
quency response  data  give  the  amplitude  of  motion  for  some  aircraft  degree  of 
freedom  in  response  to  harmonic  control  motions  at  various  frequencies. 
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2.  3. 1. 6 Acoustics  Subsystem 

The  Acoustics  Subsystem  includes  packages  for  the  empirical  and  theoretical  anal- 

I 

yses  to  define  the  acoustic  emissions  of  the  aircraft.  The  hierarchy  diagram  of 

» 

the  subsystem  (Figure  12)  shows  each  of  the  packages  representing  one  of  the  con- 
tributing factors  to  the  overall  sound  level. 

The  Rotor  Sound  Package  contains  subpackages  for  the  sound  of  the  main,  tail,  and 
tilt  rotors. 

The  Engine  Sound  Package  contains  representations  for  two  basic  sources:  inlet 
and  exhaust  sound.  Installation  effects,  engine  type,  duct  and  exhaust  treatments, 
and  governor  characteristics  are  taken  into  account. 

The  Gearbox  Sound  Package  includes  a number  of  subpackages:  main  transmis- 
sion, engine  gearbox,  accessory  gearing,  tail  rotor  gearboxes,  and  interconnect 
gearing  and  shafting.  Type  of  gearing,  house/case  sound  transmissibility,  isola- 
tion, and  installation  effects  are  considered. 

The  Accessories  Sound  Package  contains  several  subpackages  representing  oil 
cooler  fan(s),  hydraulic  system  pumps,  bypass  valves,  ECU,  APU,  ventilation 
fans  and  blowers,  generator,  alternator,  and  electrical/avionics  equipment.  Ac- 
cessory type,  operating  mode,  and  installation  effects  are  taken  into  account. 

f' 

The  Sound  Propagation  Package  provides  a means  to  trace  the  sound  from  the 
sources  represented  by  the  other  four  packages  to  an  observer.  It  will  account  for 

* L 

sound  dissipation  in  the  air,  through  and  around  materials  and  structures,  and  the 
mixed  airflows. 

r 

Input  to  the  Acoustics  Subsystem  includes  the  aircraft  position  relative  to  the  ob- 
server, free- fie  Id  or  restricted  environment,  flight  conditions,  rotor  orientation, 
englne/drive  system/accessory  location  and  orientation,  airframe  interference, 
sound  transmission  loss,  and  the  airmass  properties.  The  processes  encompass 
the  major  external  and  internal  sound  sources  and  their  propagation.  Output 
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includes  the  near-field,  far-field,  and  internal  sound  levels  and  the  sound  signa- 
ture at  detection  ranges. 


2. 3. 1. 7 Aeroelastic  Stability  Subsystem 

The  packages  of  the  Aeroelastic  Stability  Subsystem  calculate  the  aeroelastic  sta- 
bility characteristics  of  the  aircraft.  Stability  characteristics  are  cons;-  .-red 
aeroelastic  when  strongly  influenced  by  the  elastic  deformation  of  the  rotor,  the 
airframe,  or  other  components  of  the  aircraft.  The  hierarchy  diagram  of  the  sub- 
system (Figure  13)  indicates  three  approaches  to  the  calculation  of  aeroelastic 
stability.  These  approaches  allow  the  user  to  select  a method  according  to  the 
complexity  of  the  simulation  model  and  the  nature  of  instability  to  be  located. 

Thus  different  methods  may  be  used  for  flutter  calculations  and  for  ground  reso- 
nance. 

The  Linear  Aeroelastic  Stability  Analysis  Package  uses  linear  differential  equa- 
tions with  constant  coefficients  and  is  thus  similar  to  the  Stability  and  Control  Sub- 
system. The  necessary  derivatives  are  first  generated  so  that  the  equations  of 
motion  may  be  formulated.  The  eigenvalue  problem  is  then  solved  for  the  frequen- 
cies, damping  coefficients,  and  aeroelastic  mode  shapes. 

The  Floquet  Analysis  Package  uses  an  analysis  that  was  derived  for  linear  differ- 
ential equations  with  periodic  coefficients.  The  damping  coefficients  are  deter- 
mined from  the  eigenvalues  of  the  Floquet  transition  matrix.  Several  methods  are 
currently  available  to  calculate  the  transition  matrix. 

The  Aeroelastic  Stability  Postprocessing  Package  generates  a time  history  of  the 
parameters  of  interest  in  the  stability  analysis.  One  or  more  numerical  tech- 
niques may  at  that  point  be  applied  to  the  time-history  data  in  order  to  obtain  the 
frequencies  and  damping  coefficients. 

All  three  packages  have  the  same  input  and  the  same  output.  Input  required  in- 
cludes simulation  model  data  and  flight  conditions.  Output  includes  the  frequencies 
and  damping  coefficients  that  define  the  aeroelastic  stability. 
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2.3. 1.8  General  Mathematical  Operations  Subsystem 

The  General  Mathematical  Operations  Subsystem  consists  of  a set  of  general- 
purpose  mathematical  analysis  packages  to  be  used  as  utilities  by  other  software 
elements  of  the  System.  The  packages  of  the  General  Mathematical  Operations 
Subsystem  are  the  type  of  procedures  that  might  be  extracted  from  NASTRAN  or 
some  other  source.  Packages  In  this  subsystem  are  Identified  In  Figure  14. 

2. 3. 1. 9 External  Models  Interface  Subsystem 

To  satisfy  the  requirements  of  the  Baseline  Type  A System  Specification  for  the 
external  models  functional  capability,  the  External  Models  Interface  Subsystem  Is 
Included  In  the  Technology  Component.  The  capability  for  all  external  models  Is 
Included  In  this  subsystem.  The  hierarchy  diagram  for  the  subsystem  (Fig- 
ure 15)  indicates  the  potential  for  adding  packages  as  external  models  are  defined. 

2. 3. 1. 10  Accuracy  Assessment  Subsystem 


The  Accuracy  Assessment  Subsystem  consists  of  the  packages  necessary  to  pro- 
vide the  accuracy  assessment  functional  capability  of  the  Baseline  Type  A System 
Specification.  The  four  packages  are  shown  in  the  hierarchy  diagram  for  this  sub- 
system, Figure  16. 

The  Set  Up  Accuracy  Assessment  Cases  Package  defines  a series  of  cases  to  be 
run  with  perturbations  to  the  input  evaluation  variables.  The  equivalent  of  user 
Input  for  a series  of  cases  is  the  output  of  this  package.  Following  the  execution 

of  this  package,  the  series  of  cases  Is  run  using  a single  System  Command  Se-  < 

quence;  the  resulting  output  Is  stored  In  the  Accuracy  File. 

The  Compute  Sensitivity  Factors  Package  calculates  partial  derivatives  of  each  of 
the  output  evaluation  variables  with  respect  to  each  of  the  Input  evaluation  vari- 
ables. These  partial  derivatives  reflect  the  sensitivity  of  the  output  to  error  con- 
tent In  the  Input. 
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Figure  15.  Hierarchical  Definition  of  the  External  Models 
Interface  Subsystem 
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The  Generate  Expected  Values  and  Ranges  Package  uses  sensitivity  factors  to  find 
standard  deviations  for  the  output  variables  as  a basis  for  expected  values  and 
reasonable  ranges  for  experimental  error. 

The  Compare  Computed  Versus  Experimental  Data  Package  performs  several  dif- 
ferent types  of  comparisons  to  help  the  user  evaluate  the  validity  and  accuracy  of 
the  System  results. 


2. 3. 2 Executive  Come 


The  Executive  Component  of  the  Operational  Complex  provides  the  capability  to 
(1)  read  and  verify  data  at  the  beginning  of  an  analysis  run;  (2)  construct  the  Se- 
quence Control  Table,  which  defines  the  sequence  of  software  elements  of  both  the 
Technology  Component  and  the  Executive  Component  to  be  executed  during  an  anal- 
ysis run;  (3)  execute  software  elements  of  both  the  Technology  Component  and  the 
Executive  Component;  (4)  supply  the  specified  input  data  to  the  software  elements; 
(5)  properly  format  and  route  the  output  data;  and  (6)  perform  other  services 
(e.g. , provide  diagnostic  messages)  required  to  keep  the  Operational  Complex 
functioning  smoothly  and  efficiently.  A small  portion  of  the  Executive  Component 
is  permanently  resident  in  main  memory  while  the  Operational  Complex  is  execut- 
lng.  This  is  primarily  the  portion  responsible  for  loading  load-modules  (a  load- 
module  Is  an  executable  software  entity  comprised  of  one  or  more  software 
elements).  The  Executive  Component  Is  made  up  of  the  User  Interface  Subsystem, 
the  Run-Time  Management  Subsystem,  the  Data  Base  Management  Subsystem,  and 
the  Operating  System  Service  Subsystem,  as  shown  in  the  hierarchy  diagram  (Fig- 
ure 17).  These  subsystems  are  described  in  Sections  2. 3. 2. 1 through  2. 3. 2. 4, 
respectively. 

2. 3. 2. 1 User  Interface  Subsystem 

The  User  Interface  Subsystem  receives  and  Interprets  all  direct  user  Input  and 
selects  and  formats  all  direct  user  output  whether  in  batch  mode  or  interactive 
mode.  It  also  provides  the  interactive  user  with  meaningful  and  helpful  responses 
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during  interaction  with  the  System.  The  User  Interface  Subsystem  consists  of  the 

three  packages  shown  in  the  hierarchy  diagram  (Figure  18).  The  packages  of  the  i 

User  Interface  Subsystem  are  described  below.  j 

The  User  Input  Package  reads  the  file  containing  the  input  for  an  analysis  run  and 

generates  the  Run  Data  Base  and  the  Sequence  Control  Table.  The  Run  Data  Base 

is  generated  by  first  locating  in  the  Master  Data  Base  the  descriptions  of  aircraft  < 

components  and  other  analysis  components;  maneuvers,  conditions,  and  operating 

regimes;  and  failure/damage  effects  specified  for  the  analysis.  The  data  extracted 

from  the  Master  Data  Base  is  then  augmented  or  replaced  by  data  specified  in  user  ; 

input.  (The  Master  Data  Base  is  generated  by  the  Data  Base  Support  Package  in 

the  Support  Complex;  see  Section  2.4  for  a discussion  of  the  Support  Complex. ) 

The  Sequence  Control  Table  is  generated  by  selecting  System  Command  subse- 
quences from  the  Master  Command  File,  modifying  them  as  required  by  informa- 
tion in  the  user  input,  and  concatenating  them  into  the  correct  System  Command 
Sequence  to  perform  the  analysis  specified  in  the  user  input.  (The  Master  Com- 
mand File  is  generated  by  the  Data  Base  Support  Package  in  the  Support  Complex. ) 

If  the  analysis  run  is  a restart,  the  User  Input  Package  also  uses  the  Restart  File 
created  previously  (when  data  from  an  analysis  run  was  checkpointed)  to  establish 
the  Run  Data  Base  and  the  Sequence  Control  Table.  The  User  Input  Package  checks 
the  user's  input  for  consistency  and  correctness  as  it  generates  the  Run  Data  Base 
and  the  Sequence  Control  Table,  reporting  in  diagnostic  messages  any  possible 
errors  it  detects. 

The  Interactive  Terminal  Package,  in  conjunction  with  the  Interactive  Terminal 
Management  Package  of  the  Operating  System  Service  Subsystem,  provides  all 
direct  interaction  with  a user  at  an  interactive  terminal.  The  Interactive  Terminal 
Package  supplies  responses  to  user  input  statements,  including  tutorial  Informa- 
tion designed  to  help  the  interactive  user  of  the  System.  If  any  user  requests  at 
the  terminal  require  the  use  of  other  parts  of  the  system,  the  Interactive  Terminal 
Package  Issues  a sequence  of  System  Commands  for  execution  just  as  the  User 
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Input  Package  does.  For  example,  if  a user  at  an  interactive  graphics  terminal 
requests  a plot  of  a set  of  data,  the  Interactive  Terminal  Packages  issue  System 
Commands  that  cause  a plot  subpackage  from  the  User  Output  Package  to  be  exe- 
cuted. The  resulting  plot  is  then  displayed  on  the  terminal  by  the  Interactive 
Terminal  Package. 

The  User  Output  Package  prepares  all  data  that  are  to  be  directly  output  to  a 
user.  This  preparation  includes  formatting  data  to  be  printed  and  preparing 
device-independent  plotter  instructions  for  data  to  be  plotted.  Input  to  the  User 
Output  Package,  in  addition  to  the  data  to  be  output,  is  the  specification  of  the  for- 
mat in  which  the  data  are  to  be  presented  to  the  user.  Subpackages  of  the  User 
Output  Package  (e.g. , one  which  produces  plots)  may  be  scheduled  for  execution 
at  any  point  in  the  System  Command  Sequence  for  output  of  intermediate  results 
as  desired  by  the  user. 

2. 3. 2. 2 Run-Time  Management  Subsystem 

The  Run-Time  Management  Subsystem  supervises  the  operations  that  take  place 
during  the  processing  phase  of  an  analysis  run.  This  subsystem  is  divided  into 
four  packages,  as  shown  in  Figure  19. 

The  Sequence  Control  Package  is  responsible  for  the  execution  in  the  proper  order 
of  System  Commands  from  the  Sequence  Control  Table.  The  Sequence  Control 
Table  is  produced  by  the  User  Input  Package  of  the  User  Interface  Subsystem.  The 
System  Commands  in  the  Sequence  Control  Table  are  of  two  types: 

• An  execution  command  names  a software  element  to  be  executed  and 
gives  a set  of  parameters  for  the  software  element.  The  Run-Time 
Control  Package  is  called  to  execute  this  type  of  command.  The  large 
majority  of  the  software  elements  to  be  executed  are  software  elements 
of  the  Technology  Component.  Some,  however,  will  be  from  the  Exec- 
utive Component.  Examples  of  Executive  Component  software  elements 
are  the  execution  of  the  Checkpoint  Package  to  take  a checkpoint  at 
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any  point  in  the  System  Command  Sequence  or  the  execution  of  one  of 
the  subpackages  of  the  User  Output  Package  to  print  or  plot  any  com- 
bination of  intermediate  results  in  any  available  format. 

• A sequence  control  command  causes  the  Sequence  Control  Package  to 
begin  command  interpretation  at  a new  place  in  the  Sequence  Control 
Table.  These  commands  may  be  conditional,  in  which  case  the  Se- 
quence Control  Package  evaluates  the  condition  to  determine  whether 
or  not  the  change  of  sequence  is  actually  to  occur. 

The  Run-Time  Control  Package  provides  the  capability  to  (1)  load  a load-module 
for  execution,  (2)  verify  that  the  required  data  are  available  to  software  elements 
and  satisfy  feasibility  criteria,  and  (3)  begin  execution  of  software  elements.  In 
the  process  of  performing  this  task,  the  Run-Time  Control  Package  increments  a 
counter  associated  with  the  software  element  being  called  and  updates  other 
performance-measurement  statistics  as  required.  The  Run-Time  Control  Package 
also  interrogates  diagnostic  indicators  returned  after  a software  element  has  exe- 
cuted and  produces  appropriate  diagnostic  messages. 

The  Checkpoint  Package  saves  on  a Checkpoint  File  all  of  the  information  required 
to  define  the  state  of  an  analysis  run  so  that  the  information  can  be  used  in  a sub- 
sequent run  without  reexecuting  the  software  elements  which  create  the  informa- 
tion. The  Checkpoint  Package  specifically  saves  on  a Checkpoint  File  the  contents 
of  the  sets  of  the  Run  Data  Base  indicated  in  a Checkpoint  System  Command.  The 
information  on  the  Checkpoint  File  is  organized  so  that  the  analysis  run  can  be  re- 
started immediately  following  any  completed  Checkpoint  System  Command.  Upon 
restart,  the  user  may  modify  either  (1)  the  user  input  data  required  by  any  System 
Command  following  the  point  selected  for  restart,  (2)  the  System  Commands  sub- 
sequent to  the  selected  restart  point,  (3)  output  reporting  anywhere  in  the  System 
Command  Sequence,  or  (4)  any  combination  of  the  preceding  three  possibilities. 
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The  Internal  System  Error  Analysis  Package  generates  information  needed  to 
identify  the  cause  of  internal  System  errors  (i.e. , errors  not  in  user  input).  Upon 
detection  of  a possible  software  error,  the  type  of  error  detected  is  reported,  the 
location  in  the  software  where  the  error  surfaced  is  identified,  the  file  (If  appro- 
priate) on  which  the  error  occurred  is  specified,  and,  depending  on  the  user's 
option,  a dump  of  either  the  software  clement  wherein  the  error  surfaced  or  the 
entire  memory  region  assigned  to  the  Operational  Complex  is  generated.  Regard- 
less of  the  error  detected,  reports  describing  current  memory  utilization,  file 
activity  since  run  initiation,  and  execution  statistics  since  the  start  of  the  run  are 
also  produced. 

2. 3. 2. 3 Data  Base  Management  Subsystem 

The  Data  Base  Management  Subsystem  provides  the  capability  to  access  the  data 
in  the  Master  Data  Base  and  the  Run  Data  Base.  In  order  that  the  System  be  modu- 
lar and  to  allow  for  the  development  of  Technology  Component  software  elements 
over  an  extended  period  of  time,  the  data  required  for,  and  generated  by,  a soft- 
ware element  must  be  identified  other  than  by  means  of  its  location  on  disk  or  its 
relative  location  in  a record.  The  control  of  access  to  such  data,  stored  either 
in  the  Master  Data  Base  or  the  Run  Data  Base,  is  provided  by  the  Data  Base  Man- 
agement Subsystem.  The  Data  Base  Management  Subsystem  uses  a dictionary 
which  contains  the  name  and  location  of  data- items,  arrays  of  data -items,  and 
sets  in  the  Master  Data  Base  or  Run  Data  Base.  A discussion  of  data-items, 
arrays,  and  sets  can  be  found  in  Section  4.2.  Software  elements  of  the  Technology 
Component  have  knowledge  only  of  the  names  of  these  data;  access  to  the  dictionary 
and  hence  to  the  location  of  the  data  is  restricted  to  software  elements  of  the  Data 
Base  Management  System.  If  the  format  of  the  Master  Data  Base  is  changed 
during  the  life  of  the  System,  only  the  dictionary  need  be  changed;  the  software 
elements  that  use  the  data  can  remain  intact,  thus  avoiding  costly  maintenance 
effort.  The  packages  of  the  Data  Base  Management  Subsystem  that  allow  access 
to  the  Master  Data  Base  and  the  Run  Data  Base  and  that  allow  update  of  the  Run 


Data  Base  are  shown  in  Figure  20.  The  process  of  creating  and  updating  the 
dictionary  and  the  Master  Data  Base  is  done  by  the  Data  Base  Support  Package  in 
the  Support  Complex  of  the  System  (see  Section  2.4). 

The  Data  Storage  Package  stores  the  data  supplied  to  it  in  locations  in  the  Run 
Data  Base  associated  with  the  names  of  the  data  supplied  to  it.  The  Data  Storage 
Package  stores  individual  data- items,  arrays  of  data-items,  or  sets. 

The  Data  Retrieval  Package  uses  the  dictionary  to  locate  requested  data  in  either 
the  Master  Data  Base  or  the  Run  Data  Base,  reads  tne  data  from  the  data  base, 
and  makes  it  available  to  the  requester.  Individual  data-items,  arrays  of  data- 
items,  or  sets  may  be  requested  from  the  Data  Retrieval  Package. 

2. 3. 2. 4 Operating  System  Service  Subsystem 

To  maximize  the  transportability  of  the  System  among  computers,  all  computer- 
dependent,  operating- system  -dependent , and  peripheral-device-dependent 
capabilities  required  by  the  Operational  Complex  are  localized  in  one  subsystem: 
the  Operating  System  Service  Subsystem.  However,  the  interfaces  between  the 
capabilities  provided  by  this  subsystem  and  all  other  Operational  Complex  subsys- 
tems are  independent  of  the  host  computer,  the  host  operating  system,  and  the 
peripheral  devices  of  the  host  computers.  This  host-computer-independent  ap- 
proach therefore  preserves  the  transportability  characteristic  of  all  other  Opera- 
tional Complex  subsystems. 

To  minimize  development  costs  associated  with  the  Operating  System  Services 
Subsystem,  all  subsystem  capabilities  maximize  the  use  of  services  provided  by 
the  host  operating  system  and  minimize  the  use  of  software  expressly  developed 
or  purchased  for  the  System.  To  simplify  the  use  of  the  capabilities  provided  by 
this  subsystem,  all  services  are  provided  in  the  form  of  lnvocable  modules  with 
computer-independent  calling  sequences.  This  direct-linkage  approach  eliminates 
the  introduction  of  any  software  linkage  overhead  which  would  be  incurred  if  the 
linkage  were  indirect. 


f 


- | 


109 


1 


STORE  DATA  IN  RUN  RETRIEVE  DATA  FROM 

DATABASE  MASTER  DATA  BASE  OR 

RUN  DATA  BASE 


Figure  20.  Hierarchical  Definition  of  the  Data  Base 
Management  Subsystem 
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The  capabilities  provided  by  the  Operating  System  Service  Subsystem  correlate 
with  services  commonly  provided  by  modern  operating  systems.  As  presented  in 
Figure  21,  five  sets  of  operating-system-like  services  (capabilities)  are  provided 
by  this  subsystem.  These  five  sets  of  services  directly  correlate  to  five  packages: 
the  File  Management  Package,  the  Interactive  Terminal  Management  Package, 
the  Program  Management  Package,  the  Storage  Management  Package,  and  the 
Cost  Assessment  and  Diagnostic  Services  Package.  Because  maximum  use  is 
made  of  host  computer  operating  system  services,  each  of  the  five  packages  is 
composed  of  one  subpackage  for  each  host  computer  family.  (The  Host  1 computer 
family  consists  of  IBM  S/370s  and  S/360s;  the  Host  2 computer  family  consists  of 
CDC  6000  and  CYBER  series  computers.)  However,  there  is  only  one  such  sub- 
package of  each  package  on  any  given  host  computer:  the  subpackage  which  uses 
the  services  provided  by  the  host  operating  system. 

The  File  Management  Package  provides  the  following  physical  input/output  services 
(e.g. , read,  write,  position): 

1.  Prepare  a file  for  input/output 

2.  Find  a specified  record 

3.  Read  a record 

4.  Add  a record 

5.  Replace  a record 

6.  Update  a record 

7.  Delete  a record 

8.  Terminate  file  input/output 

9.  Position  a file  for  subsequent  input /output 

The  Interactive  Terminal  Management  Package  provides  the  Input/output  interface 
between  the  System  and  the  physical  interactive  or  graphics  terminals  employed 
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by  the  user  to  Interact  with  the  System.  Specific  capabilities  provided  by  this 

package  include  the  following:  i 

f 

1.  Accept  a message  entered  by  the  user  at  an  Interactive  terminal 

2.  Notify  the  Interactive  Terminal  Package  whenever  a user  message  is 
received 

3.  Translate  user-entered  messages  into  a device-independent  format  for 
subsequent  processing  by  the  System 

4.  Reformat  System-generated  displays  (textual  and/or  graphical)  into 
a device-dependent  format  for  subsequent  presentation  on  the  user 
terminal 

The  Program  Management  Package  provides  the  following  services  for  managing 
load- modules: 

1.  Bring  a load-module  into  memory  if  not  already  in  memory 

2.  Execute  a load-module  (this  is,  in  effect,  a subroutine  call) 

3.  Transfer  control  to  a load-module  (when  a module  m^  transfers  con- 
trol to  a module  m , m0  returns  to  the  invoker  of  m , rather  than 

2 2 1 

to  m^) 

4.  Suspend  or  terminated  load-module  execution 

5.  Delete  a load-module  from  memory  if  there  are  no  outstanding  re- 
quests to  execute  it 

The  Storage  Management  Package  provides  the  following  services  for  managing 
the  utilization  of  computer  memory  assigned  to  the  Operational  Complex: 

1.  Aoqulre  a block  of  memory 

2.  Release  a block  of  aoqulred  memory 
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The  Cost  Assessment  and  Diagnostic  Services  Package  provides  the  following 
services  needed  to  support  cost  assessment  processing  and  diagnostic  processing: 

1.  Generate  meaningful  dumps  of  specified  memory  locations 

2.  Provide  current  date  (Julian  and  Gregorian) 

3.  Provide  current  clock  time  (seconds  since  midnight) 

4.  Route  a message  to  the  computer  operator 

5.  Provide  the  estimated  cost  of  a run 

4 

The  estimation  of  run  cost  is  based  upon  a computer-independent  cost  algorithm. 

However,  the  algorithm  does  allow  the  specification  of  factors  to  account  for  dif- 
fering performance  characteristics  of  host  computers. 

2.4  SUPPORT  COMPLEX 

Successful  development  of  the  Second  Generation  Comprehensive  Helicopter  Analy- 
sis System  is  dependent  upon  a comprehensive  plan  for  developing  and  maintaining 
the  System.  A principal  result  of  the  Predesign  Phase  contract  is  such  a plan,  a 
summary  of  which  is  presented  in  Section  5.  However,  for  such  a sophisticated 
System,  the  mere  existence  of  a comprehensive  plan  for  its  development  and 
maintenance  will  not  ensure  its  success.  Automated  support  of  the  development 
and  maintenance  efforts  is  also  needed  if  the  high  quality  standards  specified  in 
Sections  3.4  and  4 of  the  Baseline  Type  A System  Specification  are  to  be  realized. 

This  automated  support  is  provided  in  the  Support  Complex. 

The  automated  support  tools  defined  in  the  Support  Complex  are  also  designed  to 
aid  the  methods  developer  in  experimenting  with  and  developing  new  or  advanced 
analysis  capabilities.  For  this  reason,  the  Support  Complex  is  Intended  to  be  an 
Integral  part  of  the  Long  Range  System,  i.e. , the  Support  Complex  contains  auto- 
mated  tools  to  minimize  the  costs  of  development  during  the  Development  Phase, 
to  control  the  System  configuration  during  the  Maintenance  Phase,  and  to  aid  the 
methods  developer  in  experimenting  with  or  developing  new  or  advanced  analysis 
capabilities  throughout  the  life  cycle  of  the  System. 
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Figure  22  depicts  the  four  categories  of  automated  support  necessary  to  ensure  a 
successful  System  development  and  maintenance  effort.  These  four  support  cate- 
gories correspond  to  the  four  Support  Complex  subsystems:  the  Development  Sup- 
port Subsystem,  the  Testing  Support  Subsystem,  the  Configuration  Management 
Support  Subsystem,  and  the  Documentation  Support  Subsystem. 

The  Development  Support  Subsystem  provides  automated  tools  needed  to  generate 
the  System  software  in  a cost-effective  manner  and  to  ensure  conformance  of  the 
software  to  the  high  quality  standards  specified  in  Section  3.4  of  the  Baseline 
Type  A System  Specification.  The  Testing  Support  Subsystem  provides  automated 
tools  needed  to  minimize  testing  costs  and  to  demonstrate  conformance  to  the  qual- 
ity assurance  standards  specified  in  Section  4 of  the  Baseline  Type  A System  Speci- 
fication. The  Configuration  Management  Support  Subsystem  provides  automated 
tools  needed  to  manage  the  System  software  and  data  configuration  and  to  install  the 
System  on  Government-specified  host  computers,  as  specified  in  Section  3.4  of  the 
Baseline  Type  A System  Specification.  The  Documentation  Support  Subsystem  pro- 
vides automated  tools  needed  to  aid  in  producing  the  quality  software  documentation 
required  in  Section  3.4  of  the  Baseline  Type  A System  Specification. 

To  minimize  potential  development  costs  associated  with  the  automated  tools  to  be 
provided  in  the  Support  Complex,  maximal  use  is  made  of  automated  tools  provided 
by  host  computer  operating  systems.  Although  this  approach  naturally  results  in 
some  Support  Complex  software  differences  between  the  two  host  computer  fami- 
lies specified  as  a baseline  for  the  Predesign  Phase,  resulting  development  and 
maintenance  costs  are  minimized.  These  differences  impact  the  architecture  of  the 
Support  Complex  at  a very  detailed  level  and  therefore  have  no  effect  on  the  archi- 
tecture presented  in  Figure  22  or  in  any  other  figure  in  Section  2.4. 

2.4.1  Development  Support  Subsystem 

The  Development  Support  Subsystem  aids  the  software  development  activities  in- 
volved in  generating  the  System  software.  These  activities  Include  not  only  gener- 


ating  the  System  software  in  a cost-effective  manner  but  also  verifying  that  the 
software  conforms  to  the  high  quality  standards  specified  in  Section  3. 4 of  the 
Baseline  Type  A System  Specification. 


Figure  23  presents  the  six  packages  necessary  to  ensure  both  cost-effective  soft- 
ware development  and  high-quality  software.  These  six  packages  are:  the  Text 
Editor  Package,  the  Structured  Preprocessor  Package,  the  FORTRAN  Compiler 
Package,  the  Assembler  Package,  the  Automated  Code  Auditor  Package,  and  the 
Link  Editor  Package.  These  six  packages  provide  capabilities  to  aid  in  the  genera- 
tion of  source  code,  the  translation  of  source  code  into  object  code,  the  verification 
of  source  code  conformance  to  programming  standards,  the  merging  of  object  code 
into  executable  load-modules,  and  the  preparation  of  the  data  required  by  each  of 
these  support  capabilities.  The  Text  Editor  Package,  the  FORTRAN  Compiler 
Package,  the  Assembler  Package,  and  the  Link  Editor  Package  are  each  composed 
of  two  subpackages,  one  for  each  host  computer  family. 

2.4. 1.1  Text  Editor  Package 

The  Text  Editor  Package  provides  a convenient  and  cost-effective  means  to  create, 
update,  and  edit  alphanumeric  data.  The  Text  Editor  supports  either  an  interac- 
tive or  a batch  user  interface.  The  Text  Editor  can  be  used  to  create,  update,  and 
edit  seven  types  of  alphanumeric  data: 

1.  Standardized  definitions  of  FORTRAN  COMMON  blocks  for  use  in 
FORTRAN  modules  which  directly  access  data  from  COMMON  blocks 

2.  Operating  system  control  language  procedures  needed  to  execute  ele- 
ments of  the  System 

3.  Data  needed  to  execute  tests 

4.  Source  code  for  source  modules 

5.  Global  macros  for  access  by  assembly  language  modules 
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6.  Link  editor  control  statements  needed  to  create  System  load-modules 

7.  Other  user-defined  alphanumeric  text  data  (e.  g. , documentation) 

The  Text  Editor  Package  is  composed  of  one  Text  Editor  Subpackage  for  each  host 
development  computer  family.  On  a single  host  development  computer,  CSC  rec- 
ommends the  use  of  a single  Text  Editor  Subpackage:  the  one  supplied  by  the  host 
operating  system. 

2.4. 1.2  Structured  Preprocessor  Package 

The  Structured  Preprocessor  Package  facilitates  the  use  of  top-down  structured- 
programming  concepts  in  FORTRAN  source  modules.  This  package  provides 
ANSI-1966  FORTRAN  language  extensions  which  correspond  to  the  following 
structured-programming  control  statements: 

1.  IF  -THEN -ELSE 

2.  DO  WHILE 

3.  DO  UNTIL 

4.  DO  FOR 

5.  CASE 

The  Structured  Preprocessor  Package  translates  structured-programming  control  , ■ 

statements  to  transportable  FORTRAN  statements  and  merges  them  with  the  re- 
maining FORTRAN  statements.  The  resulting  FORTRAN  module  can  then  be  com- 

.. 

piled  by  the  FORTRAN  compiler.  Thus  FORTRAN  modules  can  be  written  using 

* 

structured-programming  control  statements  despite  the  limitations  of  the  FORTRAN 
compiler. 

2.4. 1.3  FORTRAN  Compiler  Package 

The  FORTRAN  Compiler  Package  translates  ANSI-1966  FORTRAN  source  modules 
into  object  modules  needed  to  build  executable  load  modules.  The  FORTRAN  Com- 
piler Package  is  composed  of  one  FORTRAN  Compiler  Subpackage  for  each  host 
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computer  family.  On  a single  host  computer,  there  will  be  a single  FORTRAN 
Compiler  Subpackage.  This  compiler  will  be  provided  by  the  host  operating  sys- 
tem. 


2. 4. 1. 4 Assembler  Package 

The  Assembler  Package  translates  assembly  language  source  modules  into  object 
modules  needed  to  build  load-modules.  The  Assembler  Package  allows  the  defini- 
tion and  utilization  of  both  global  and  local  macros.  This  package  also  permits 
access  to  FORTRAN  named  COMMON  blocks. 

The  Assembler  Package  is  composed  of  one  Assembler  Subpackage  for  each  host 
computer  family.  On  a single  host  computer,  there  is  a single  Assembler  Subpack- 
age. This  subpackage  is  the  Assembler  provided  by  the  host  operating  system. 

2.4. 1.5  Automated  Code  Auditor  Package 

The  Automated  Code  Auditor  Package  checks  individual  source  modules  for  con- 
formance to  programming  standards  specified  in  Programming  Standards  for  the 

35 

Second-Generation  Comprehensive  Helicopter  Analysis  System.  For  FORTRAN 
source  modules,  conformance  is  checked  only  for  those  standards  which  can  be 
verified  in  a single  scan  of  the  source  code.  For  assembly  language  source  mod- 
ules, only  the  format  of  the  module  prologue  and  the  organization  of  module  code 
are  checked.  Conformance  to  all  remaining  standards  is  verified  via  a visual 
Inspection  of  the  compilation  or  assembly  listing.  The  size,  complexity,  trans- 
portability, and  multicontractor  development  of  the  System  require  that  program- 
ming standards  be  rigidly  enforced.  The  use  of  an  automated  capability  to  verify 


35 

PROGRAMMING  STANDARDS  FOR  THE  SECOND-GENERATION  COMPREHEN- 
SIVE HELICOPTER  ANALYSIS  SYSTEM,  Applied  Technology  Laboratory, 

U.S.  Army  Research  and  Technology  Laboratories,  Fort  Eustis,  Virginia,  to 
be  published. 
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conformance  to  specified  programming  standards  minimizes  the  manual  effort  and, 
hence,  the  cost  which  would  be  needed  if  such  an  automated  capability  were  not 
available. 

2.4. 1.6  Link  Editor  Package 

The  Link  Editor  Package  combines  user-supplied  object  modules  into  executable 
load-modules.  Object  modules  which  are  not  user-supplied  but  which  are  invoked 
by  user-supplied  object  modules  are  automatically  extracted  from  a user-specified 
library  of  object  modules  and  automatically  inserted  into  the  resulting  load-module. 

An  overlay  capability  is  provided  which  allows  the  user  to  specify  the  module  and 
the  COMMON  block  composition  of  each  defined  overlay  segment.  Resulting  load- 
modules  can  be  stored  on  peripheral  storage  for  subsequent  execution  without  ne- 
cessitating a re-creation  of  the  load-modules. 

The  Link  Editor  Package  is  composed  of  one  Link  Editor  Subpackage  for  each  host 
computer  family.  On  a single  host  computer,  there  is  a single  Link  Editor  Sub- 
package. This  subpackage  is  the  Link  Editor  provided  by  the  host  operating  system. 

2.4.2  Testing  Support  Subsystem 

The  Testing  Support  Subsystem  provides  automated  tools  for  module,  CPCI,  and 
integration  testing,  both  to  reduce  testing  costs  and  to  demonstrate  conformance 
to  the  quality  assurance  pi  ovisions  specified  in  Section  4 of  the  Baseline  Type  A 
System  Specification.  Figure  24  presents  the  three  testing  tools  provided  by  the 
Testing  Support  Subsystem.  These  three  tools  correspond  to  three  software 
packages:  the  Test  Data  Generation  Package,  the  Decision  Path  Monitor  Package, 
and  the  Execution  Test  Monitor  Package.  The  Test  Data  Generation  Package  and 
the  Execution  Test  Monitor  Package  both  contribute  toward  reducing  the  costs  of 
testing  by  simplifying  the  tasks  of  generating  test  data  and  of  debugging  software 
code.  The  Decision  Path  Monitor  Package  provides  an  objective  assessment  of 
the  scope  of  module,  CPCI,  and  integration  testing. 
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Figure  24.  Hierarchical  Definition  of  the  Testing  Support  Subsystem 
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2.4.2. 1 Test  Data  Generation  Package 

The  Test  Data  Generation  Package  simplifies  the  task  of  providing  test  data  for  use 
in  testing  modules  or  CPCIs.  This  package  provides  a quick  and  convenient  means 
of  formatting  and  organizing  test  data  for  direct  use  by  a module  or  a CPCI.  The 
generated  test  data  is  derived  from  user-supplied  (i.e. , flight  test)  data,  from 
data  extracted  from  either  the  Master  Data  Base  or  the  Master  Command  File, 
or  from  an  already  existing  file  of  test  data.  The  generated  test  data  is  formatted 
and  organized  so  that  it  can  be  accessed  at  test-execution  time  by  using  the  soft- 
ware  services  provided  by  the  Data  Base  Management  Subsystem  of  the  Operational 
Complex.  This  frees  the  package  user  from  any  dependency  on  the  format  and 
organization  of  the  generated  file  of  test  data,  thus  minimizing  the  need  to  generate 
special  software  to  test  a module  or  a CPCI. 

2. 4. 2. 2 Decision  Path  Monitor  Package 

The  Decision  Path  Monitor  Package  monitors  the  execution  of  decision  paths  and 
module  invocations  during  tests.  This  capability  is  used  to  objectively  determine 
the  scope  of  testing  performed.  Decision  path  monitoring  is  used  to  determine  the 
scope  of  module  tests;  module  invocation  monitoring  is  used  to  determine  the  scope 
of  CPCI  and  integration  tests. 

i 

The  Decision  Path  Monitor  Package  identifies  decision  paths  and  module  invocations 
in  FORTRAN  source  modules;  inserts  invocations  (CALLS)  to  instrumentation  data 
collection  modules  at  the  beginning  of  each  identified  decision  path  and  immediately  - 5 

preceding  each  module  invocation  in  the  original  source  module;  and  identifies,  * 

1 , based  on  the  collected  instrumentation  data,  the  number  of  times  each  decision  path 

and  module  invocation  was  executed  during  a test.  A decision  path  is  defined  for 
each  serial  sequence  of  instructions  which  can  be  executed  following  a conditional 
1 branch  or  loop  definition  statement.  Module  Invocations  Include  both  direct  module 

invocations  (e.g. , FORTRAN  CALL  statement)  and  indirect  module  invocations 
(e.  g. , FORTRAN  external  function  reference). 
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The  Decision  Path  Monitor  Package  provides  an  objective  means  to  determine 
whether  the  scope  of  module,  CPCI,  and  integration  tests  conforms  to  the  stand- 
ards specified  in  Section  4 of  the  Baseline  Type  A System  Specification.  It  is  used 
both  to  determine  whether  all  decision  paths  have  been  tested  in  each  module  and 
to  determine  whether  all  module  invocations  have  been  executed  in  a CPCI  (CPCI 
testing)  and  in  a collection  of  CPCIs  (integration  testing).  Without  the  objective, 
quantitative  monitoring  capability  of  the  Decision  Path  Monitor  Package,  the 
assessment  of  the  scope  of  module,  CPCI,  and  integration  testing  would  have  to 
rely  on  qualitative  and  often  imprecise  human  judgments. 

2. 4. 2. 3 Execution  Test  Monitor  Package 

The  Execution  Test  Monitor  Package  provides  interactive  and  batch  debugging  capa- 
bilities for  testing  individual  modules  and  CPCIs  of  the  System.  The  Execution 
Test  Monitor  Package  provides  specific  capabilities  to  request 

1.  Intermediate  execution  data  displays  for  user-specified  variables  at 
user-selected  points  within  modules 

2.  Intermediate  dumps  of  selected  portions  of  memory 

3.  Trace  of  all  module  invocations  and  contents  of  associated  calling  se- 
quence parameters 

The  Execution  Test  Monitor  Package  uses  execution-time  debugging  capabilities 
provided  by  the  host  computer  operating  system.  This  reliance  on  host  operating 
system  debugging  capabilities  results  in  multiple  Execution  Test  Monitor  Sub- 
packages, one  for  each  host  computer  family.  On  a single  host  computer,  there 
is  only  one  Execution  Test  Monitor  Subpackage:  the  one  provided  by  the  host 
operating  system. 

2.4.3  Configuration  Management  Support  Subsystem 

The  Configuration  Management  Support  Subsystem  provides  automated  support  both 
for  controlling  the  System  software  and  data  configuration  and  for  installing  the 
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System  software  and  data  on  Government-specified  host  computers,  as  specified  in 
Section  3.4  of  the  Baseline  Type  A System  Specification.  For  software  systems, 
configuration  control  must  address  documentation  (development  and  product  specifi- 
cations), software,  and  data.  Although  controlling  the  documentation  elements  of 
System  configuration  lends  itself  to  manual  procedures,  such  is  not  the  case  with 
System  software  and  data.  Successful  management  of  System  software  and  data 
configuration  r equires  that  manual  procedures  be  supported  by  automated  tools.  It 
is  this  requirement  that  is  supported  by  the  Configuration  Management  Support  Sub- 
system. 

Figure  25  presents  the  three  sets  of  configuration  management  support  tools  needed 
both  to  effectively  control  the  System  software  and  data  configuration  and  to  install 
the  System  software  and  data  on  Government-specified  host  computers.  These 
three  sets  of  automated  support  tools  correspond  to  three  software  packages:  the 
Data  Base  Support  Package,  the  Configuration  Control  Package,  and  the  System 
Installation  Package.  These  three  packages  provide  support  capabilities  which  aid 
in  controlling  the  content  of  the  Master  Data  Base  and  the  Master  Command  File; 
controlling  the  System  software  and  data  configuration;  generating  backup  copies  of 
all  System  software  libraries  and  data  files;  restoring  System  software  libraries 
and  data  files;  generating  installation  tapes  for  System  software  libraries  and  data 
files;  and  installing  the  System  on  another  host  computer. 

2. 4. 3. 1 Data  Base  Support  Package 

The  Data  Base  Support  Package  controls  the  content  of  the  subset  of  System  data 
reflected  by  the  Master  Data  Base  and  the  Master  Command  File.  Because  the 
content  of  the  Master  Data  Base  and  the  Master  Command  File  are  critical  to  an 
effective,  orderly  utilization  of  the  Operational  Complex,  controls  are  provided 
over  all  modifications  to  them.  This  package  maintains  audit  trails  for  all  modi- 
fications. Special  authorization  codes,  which  are  under  control  of  each  Installa- 
tion, are  required  before  modifications  are  permitted.  The  control  over  the 
content  of  the  Master  Data  Base  and  the  Master  Command  File  at  a computer 
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Figure  25.  Hierarchical  Definition  of  the  Configuration 
Management  Support  Subsystem 
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facility  is  intended  to  be  vested  in  a single  group  of  data  base  administrators.  All 
modifications  to  the  Master  Data  Base  and  the  Master  Command  File  are  made  by 
the  data  base  administrators.  (Although  CSC  strongly  recommends  this  type  of 
control,  there  are  no  explicit  or  implicit  software  design  assumptions  that  require 
a user  organization  to  exercise  it. ) It  is  because  of  this  centralization  that  the 
Data  Base  Support  Package  provides  rigid  controls  over  all  modifications  to  the 
Master  Data  Base  and  the  Master  Command  File.  The  Data  Base  Support  Package 
also  provides  a capability  to  generate  reports  showing  the  content  of  the  Master 
Data  Base  and  Master  Command  File. 

2 . 4 . 3 . 2 Configuration  Control  Package 

The  Configuration  Control  Package  provides  the  following  tools  needed  to  control 
the  System  software  and  data  configuration,  in  accordance  with  the  System  Devel- 
opment Plan  (see  Section  5): 

1.  Maintenance  of  multiple  versions  of  the  System 

2.  Protection  from  unauthorized  modification  of  all  System  software  li- 
braries and  data  files 

3.  Generation  of  backup  copies  of  System  software  libraries  and  data  files 

4.  Maintenance  of  both  a record  and  a copy  of  all  authorized  System  soft- 
ware and  data  modifications 

5.  Restoration  of  System  software  libraries  and  data  files  from  backup 
copies 

The  Configuration  Control  Package  uses,  to  the  maximum  possible  extent,  operating 
system  utilities  which  are  available  on  each  Government-specified  host  computer 
family  to  provide  configuration  control  tools.  This  reliance  on  host  computer  op- 
erating system  utilities  results  in  one  Configuration  Control  Subpackage  for  each 
host  computer  family.  On  a single  host  computer,  there  is  a single  Configuration 


f 

) 

I 

I 

\ 

I 

f 

Control  Subpackage  based  upon  configuration  control  tools  provided  by  the  resident 
host  operating  system. 

2. 4. 3. 3 System  Installation  Package 

The  System  Installation  Package  provides  automated  tools  to  support  the  installation 
of  the  System  on  Government-specified  target  computers.  All  System  software  and 
data  needed  for  installation  is  generated  in  magnetic  tape  format  on  a development 
computer.  The  resulting  magnetic  tapes  are  then  used  on  the  target  computer  to 
create  the  needed  System  software  libraries  and  data  files. 

The  System  Installation  Package  uses,  to  the  maximum  possible  extent,  operating 
system  utilities  which  are  available  on  both  the  development  computer  and  the  tar- 
get computer  (i.  e. , the  computer  on  which  the  System  is  installed).  This  reliance 
on  host  computer  operating  system  utilities  results  in  one  System  Installation  Sub- 
package for  each  target  host  computer  family.  Each  subpackage  supports  the  in- 
stallation of  the  System  from  one  host  computer  to  another  host  computer  in  the 
same  family.  In  addition,  the  capability  is  provided  to  install,  on  a host  computer 
which  is  not  a member  of  the  primary  (Host  1)  computer  family,  the  transportable 
System  software  and  data  developed  on  the  primary  (Host  1)  development  computer. 

This  additional  capability  is  provided  as  part  of  the  System  Installation  Subpackage 

► 

for  each  target  host  computer  family  which  differs  from  the  primary  (Host  1)  de- 
velopment computer  family. 

2.4.4  Documentation  Support  Subsystem 

» 

The  Documentation  Support  Subsystem  provides  automated  support  tools  for  gener- 
atlng  software  documentation  during  System  development  and  maintenance.  Fig- 
ure 26  presents  the  two  basic  sets  of  software  documentation  support  tools  provided 
by  this  subsystem:  the  Module  Specifications  Package  and  the  Comprehensive  , 

Cross-Reference  Package.  Both  the  Module  Specifications  Package  and  the  Com- 
prehensive Cross-Reference  Package  are  transportable;  hence  they  do  not  have 
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Figure  26. 


« 


GENERATE  MODULE 
DESIGN  SPECIFICA- 
TIONS FROM 
MODULE 
PROLOGUES 


IDENTIFY 
MODULE  AND 
COMMON  BLOCK 
CROSS-REFERENCES 


Hierarchical  Definition  of  the  Documentation 
Support  Subsystem 


> 


129 


host  computer-dependent  subpackages.  The  Module  Specifications  Package  ex- 
tracts module  design  specifications  directly  from  prologue  commentary  included 
in  module  source  code  for  direct  use  in  Type  C5  Computer  Program  Product 
Specifications.  The  Comprehensive  Cross-Reference  Package  extracts  the  module 
and  COMMON  block  cross-reference  data  direct  from  module  source  code  for 
inclusion  in  the  dictionary  of  computer  variables  specified  in  Section  3. 4. 1.5  of  the 
Baseline  Type  A System  Specification.  The  intent  of  the  System  Documentation 
Subsystem  is  to  generate  as  much  of  the  software  documentation  as  possible 
directly  from  source  modules  to  ensure  that  software  documentation  reflects  the 
software  actually  included  in  the  System  and  to  eliminate  the  potential  error  in- 
herent in  human  transcription. 

2. 4. 4.1  Module  Specifications  Package 

The  Module  Specifications  Package  extracts  directly  from  module  source  code  the 
individual  module  functional  descriptions  to  be  included  in  Type  C5  Computer  Pro- 
gram Product  Specifications.  Module  functional  description  information  is  included 

in  module  prologue  commentary,  as  specified  in  Programming  Standards  for  the 

35 

Second-Generation  Comprehensive  Helicopter  Analysis  System.  For  each  mod- 
ule, a prologue  includes  a module  description,  a logic  flow  summary  via  structured 
design  constructs  in  combination  with  English  language  phraseology,  data  and  mod- 
ule interface  specifications,  data  organization  diagrams,  and  processing  limita- 
tions. Because  this  information  includes  all  that  is  required  for  module  functional 
descriptions  in  a Type  C5  Computer  Program  Product  Specification,  a separate  and 
independent  documentation  effort  for  System  modules  is  avoided  by  using  the  Mod- 
ule Specifications  Package.  This  ensures  that  the  published  module  functional 
specifications  remain  up  to  date  with  the  actual  source  code.  In  addition,  the  use 
of  the  Module  Specifications  Package  avoids  the  very  costly  effort  of  generating  and 
maintaining  separate  module  functional  description  documentation. 
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2. 4. 4. 2 Comprehensive  Cross-Reference  Package 

An  important  element  of  documentation  specified  in  the  Baseline  Type  A System 
Specification  is  a dictionary  of  computer  variables.  Included  in  this  dictionary  is 
an  entry  for  every  module  and  COMMON  block.  For  each  module  and  COMMON 
block  entry,  a list  of  all  modules  which  reference  the  entry  is  required.  The  Com- 
prehensive Cross-Reference  Package  directly  extracts  this  cross-reference  infor- 
mation from  module  source  code.  This  package  eliminates  the  manual  effort 
necessary  to  derive  this  information  and  automatically  ensures  that  the  information 
is  complete,  correct,  and  up  to  date. 

The  cross-reference  information  is  derived  from  specification  statements  and  ex- 
ecutable statements  in  FORTRAN  source  modules  and  from  the  information  included 
in  the  prologue  of  assembly  language  source  modules.  In. FORTRAN  source  mod- 
ules, module  invocations  include  both  modules  directly  invoked  via  a CALL  state- 
ment and  modules  invoked  via  an  external  function  reference.  Two  types  of 
cross-reference  information  are  output  by  this  package:  (1)  a report  by  module 
which  indicates  by  source  statement  all  references  to  external  modules  and  all 
definitions  of  COMMON  blocks  and  (2)  a report  by  external  reference  (module  or 
COMMON  block)  which  identifies  all  modules  which  reference  the  module  or 
COMMON  block. 

2.5  SYSTEM  COMMAND  SEQUENCES  AND  DATA  FLOW 

. 

This  section  discusses  the  sequence  of  functions  to  be  performed  and  the  flow  of  , 

data  necessary  for  the  solution  of  several  typical  engineering  problems.  As  indi- 

P 

cated  in  Section  2.3,  Executive  Component  software  progresses  through  entries  in 
the  Sequence  Control  Table.  This  is  an  internal  System  table  constructed  during 
* the  input  phase  of  an  analysis  run  by  the  User  Input  Package  of  the  Executive  Com- 

ponent from  two  sources:  user  input  and  the  Master  Command  File.  These  Se- 
quence Control  Table  entries  indicate  which  Technology  Component  or  Executive 
Component  software  elements  (subpackages  or  packages)  are  to  be  executed  and  in 
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what  sequence.  Information  in  the  Sequence  Control  Table  also  provides  the  looping 
and  branching  logic  required  for  the  proper  execution  of  the  software  elements. 

The  Sequence  Control  Table  for  a given  engineering  case  indicates  a specific  execu- 
tion sequence.  This  execution  sequence,  called  a System  Command  Sequence,  is 
made  up  of  two  elements:  subsequences  and  logic  controlling  the  execution  of  the 
subsequences. 

A subsequence  is  a set  of  System  Commands  which  performs  a single,  major  System 
function  (e.  g. , finding  a steady-state  flight  condition,  calculating  stability  and  con- 
trol data,  calculating  a maneuver,  calculating  loads  and  vibrations).  Subsequences 
serve  two  main  purposes.  First,  they  facilitate  understanding  of  System  operation 
for  all  involved — the  Government,  the  developer,  and  users.  This  leads  to  better 
communication,  fewer  errors,  and  reduced  costs.  Secondly,  their  use  reduces  the 
difficulty  of  generating  the  System  Command  Sequences.  In  fact,  it  enables  the 
User  Input  Package  to  interpret  a rather  small  set  of  user  input  keywords  and  con- 
struct a valid  Sequence  Control  Table  for  the  physical  configuration  desired.  This 
flexibility  is  obtained  without  placing  a great  burden  upon  the  user. 

Subsequences  may  be  thought  of  as  building  blocks  that  may  be  combined  in  a vari- 
ety of  ways  to  create  System  Command  Sequences.  Subsequences  have  been 
grouped  together  into  sets  (types)  to  facilitate  understanding  the  relationships 
between  subsequences  and  to  facilitate  the  utilization  of  subsequences  in  building 
System  Command  Sequences.  Eight  sets  of  subsequences  have  been  Identified. 

Subsequences  within  a set  differ  from  each  other  only  in  terms  of  the  procedure 
employed  to  perform  the  function  and/or  the  level  of  detail  at  which  the  function  is  :o 
to  be  performed.  Table  1 identifies  the  eight  sets  of  subsequences  and  the  function 
of  each.  For  example,  three  Trim  Subsequences  are  currently  identified,  each 
of  which  is  used  to  solve  for  a steady-state  flight  condition.  The  major  difference 
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Table  1.  Subsequence  Sets  and  Functions 


among  the  three  Trim  Subsequences  is  the  procedure  employed  to  solve  for  a 

steady-state  flight  condition,  i.e. , the  Simultaneous  Iterate-To-Trim  procedure,  , I 

the  Decoupled  Fly-To-Trim  procedure,  or  the  Fly-To-Trim  procedure.  ( 

2.5.1  System  Command  Sequences 

By  using  subsequences,  all  of  the  problems  which  must  be  solved  by  the  System  may 

i 

be  encompassed  by  only  five  System  Command  Sequences,  one  for  each  of  the  five 
aircraft  technical  characteristics  (i.e.,  performance,  stability  and  control,  loads 
and  vibrations,  acoustics,  and  aeroelastic  stability).  These  five  sequences  are 

discussed  in  detail,  including  the  subsequences  used  and  the  flow  of  data,  in  Sec-  ' 

tions  2. 5. 1. 1 through  2.  5. 1.  5. 

2.5. 1. 1 Performance  System  Command  Sequence 

The  Performance  System  Command  Sequence,  shown  in  Figure  27,  is  the  simplest 
of  the  five  System  Command  Sequences.  The  center  portion  of  the  figure  illus- 
trates how  the  execution  processes  proceed  from  one  step  to  another.  (Each  proc- 
ess block  has  a number  associated  with  it  for  discussion  purposes.)  The  flow  of 
processing  control  is  shown  by  solid  arrows.  The  left  portion  of  the  figure  lists 
sets  of  data  which  are  input  to  the  various  processing  blocks,  as  indicated  by 
dashed  arrows.  These  data  sets  are  in  the  same  form  as  the  user's  input  (except 
for  change  of  units  or  straightforward  algebraic  combinations.  For  some  subse- 
quences these  sets  will  have  been  produced  by  other  subsequences.  The  right 
portion  of  the  figure  lists  data  sets  which  are  output  by  the  process  blocks.  Data 
sets  output  by  one  process  may  be  input  to  a later  process;  dashed  lines  show 
this.  The  data  sets  in  both  the  input  and  output  columns  of  this  and  similar  dia- 
grams that  follow  are  the  same  as  those  defined  in  Appendix  A of  the  Predesign 
Phase  Type  B5  Development  Specifications  for  the  Second-Generation  Comprehen- 
sive Helicopter  Analysts  System.  User  output  (e.g. , intermediate  and  final 
printed  or  plotted  output)  is  controlled  by  the  Executive  Component,  depending 
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Figure  27.  Performance  System  Command  Sequence 
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upon  the  standard  default  output  and  the  output  options  exercised  by  the  user.  The 

user's  output  may  include  any  or  all  of  the  output  sets.  This  is  true  for  plotted  i 

as  well  as  printed  output. 

The  following  discussion  of  the  Performance  System  Command  Sequence  is  pre- 
sented in  paragraphs  numbered  to  correspond  to  the  numbered  blocks  in  Figure 
27.  (The  numbers  8 and  11  are  omitted  in  Figure  27  to  show  the  commonality  of 
processing  present  in  all  five  System  Command  Sequences. ) 

% 

1.  Block  1 indicates  a test  to  determine  whether  more  cases  are  to  be  run 
as  part  of  this  analysis  run.  For  the  first  case,  the  answer  is  always  yes.  This 
block  demonstrates  the  looping  capability  of  the  System  Command  language  as  it 
provides  the  necessary  capability  to  run  a series  of  cases  as  part  of  one  analysis 
run.  Although  it  is  not  shown  on  this  figure,  mixing  different  types  of  cases  in  one 
analysis  run  is  permissible  (e.g. , first  a performance  case,  then  a stability  and 
control  case,  followed  by  an  acoustics  case,  and  so  on). 

2.  Block  2 shows  user-specified  changes  to  the  initial  Run  Data  Base  for 
succeeding  cases.  The  changes  may  actually  be  made  as  variations  from  the  ini- 
tial input  case  or  from  resulting  values  for  the  case  just  completed.  This  allows 
a user  to  use  hisAer  own  judgment  as  to  which  case  is  easier  to  change  or  which 
would  provide  the  best  initial  approximation  for  the  trim  solution.  Both  bin  ks  1 
and  2 are  drawn  in  dashed  lines  to  indicate  that  the  functions  they  represent  are 
performed  by  Executive  Component  software  rather  than  Technology  Component 
software. 

% 

3.  Input  to  the  Initialization  Subsequence  is  Analysis  Definition  Data,  which 

Is  based  upon  user  input  and  data  from  the  Master  Data  Base.  The  Initialization 
Subsequence  changes  units,  calculates  constant  coefficients,  sets  up  coordinate  , 

systems,  and  verifies  compatibility  of  input  data.  It  generally  prepares  the  major 

set  of  data  known  as  Simulation  Input  Data.  Rotor  modes  and  initial  geometric 


shape  of  the  rotor  wake  are  calculated  in  this  subsequence  when  these  functions 
are  needed.  All  of  the  data  compatibility  checks  are  completed  in  this  subsequence. 

4.  Block  4 indicates  a test  to  determine  whether  the  case  ends  at  this 
point.  If  the  purpose  of  this  case  was  to  check  the  input  data  or  to  find  rotor 
natural  frequencies  and  mode  shapes,  then  the  case  is  complete,  and  control  re- 
turns to  block  1. 

5.  Block  5 indicates  a test  to  determine  whether  a trim  condition  must  be 
found  for  this  case.  If  so,  as  is  normally  the  case,  control  passes  to  block  6. 
However,  several  conditions  exist  for  which  a trim  is  not  required.  If  the  data 
changes  made  between  this  case  and  a previous  case  do  not  affect  the  trim  condi- 
tion, using  the  previously  calculated  trim  condition  is  more  efficient.  An  example 
of  such  a data  change  is  a gain  or  time  constant  in  an  automatic  flight  control 
system. 

6.  The  Trim  Subsequence,  which  solves  for  a steady-state  flight  condi- 
tion according  to  the  user-specified  trim  degrees  of  freedom  and  trim  constraints, 
makes  use  of  (i.e. , invokes)  the  Simulation  Model  Subsequence  in  its  solution.  The 
output  sets  are  the  Trim  Data  and  the  Simulation  Model  Data  for  the  trim  condition. 
These  sets  may  be  saved  in  a file  for  subsequent  processing  or  plotting,  at  the 
user's  option. 

7.  Block  7 Indicates  a test  on  the  convergence  of  the  trim.  If  the  trim 
solution  attempt  has  taken  too  many  iterations  or  has  taken  too  much  time,  or  if 
some  other  convergence  problem  was  discovered,  this  case  ends  and  control 
passes  to  block  12.  For  a successful  trim,  control  is  transferred  to  block  9. 

9.  Block  9 Indicates  a test  to  determine  whether  a time-history  solution 
is  required.  This  test,  based  on  the  user's  input  for  maneuvers,  may  Indicate 
that  it  is  unnecessary  even  to  invoke  the  Maneuver  Subsequence. 
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10.  The  Maneuver  Subsequence  generates  a time-history  solution  of  the 
differential  equations  of  motion.  This  process  is  controlled  by  one  of  the  subpack- 
ages of  the  Differential  Equations  Solution  Package  of  the  General  Mathematical 
Operations  Subsystem.  The  user's  input  control  motions,  gust  disturbances,  and 
other  such  data  are  implemented  by  packages  of  the  Maneuver  Subsystem.  All  or 
part  of  the  Simulation  Model  Data  generated  may  be  saved  in  the  Time-History  Data  • 

set  for  later  processing  or  plotting.  From  block  10  control  passes  back  to  the  top 
of  the  sequence,  block  1,  to  determine  whether  more  cases  follow. 

* 

12.  Block  12  is  a test  which  occurs  following  a trim  that  did  not  converge. 

Normally,  if  one  trim  fails,  the  following  cases  fail  also,  and  the  analysis  run 
thus  terminates.  However,  in  special  cases,  each  trim  is  somewhat  independent 
of  the  others  in  the  run.  In  these  cases  the  user  has  available  an  override  control 
input  which  returns  control  to  the  top  of  the  sequence  to  execute  any  cases  which 
follow. 

2.5. 1.2  Stability  and  Control  System  Command  Sequence 

The  Stability  and  Control  System  Command  Sequence  is  shown  in  Figure  28.  The 
following  discussion  of  this  sequence  is  presented  in  the  format  used  in  Sec- 
tion 2.5. 1. 1.  Discussion  of  blocks  1 through  7,  9,  and  12  in  Figure  28  is  omitted 
because  these  blocks  are  identical  to  blocks  1 through  7,  9,  and  12  in  Figure  27. 

8.  The  Stability  and  Control  Subsequence  consists  of  System  Commands 
which  invoke  packages  of  the  Stability  and  Control  Subsystem  to  calculate  the  air- 
craft flight  stability  characteristics,  including  complex  eigenvalues  and  eigenvec- 
• tors  for  evaluating  controls-flxed  stability,  and  transfer  functions  and  frequency  * 

response  for  step  control  input  and  harmonic  control  input  (subsets  of  the  Stability 
and  Control  Data  set).  This  solution  is  based  on  linear  perturbation  equations  ob- 
tained by  use  of  the  Simulation  Model  Subsequence. 

10.  At  user- specified  times  during  the  time  history,  data  are  saved  for 
subsequent  use  by  the  Stability  and  Control  Subsequence. 

I 

i 
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11.  Following  the  generation  of  the  time  history,  the  Stability  and  Control 

i 

Subsequence  generates  the  Stability  and  Control  Data  for  the  user- selected  time 

i 

points  from  the  time  history.  Use  of  the  Stability  and  Control  Subsequence  in 
conjunction  with  time-history  data  requires  that  the  perturbation  analysis  must  be 
applicable  to  accelerated  flight  conditions. 

2.5. 1.3  Loads  and  Vibrations  System  Command  Sequence 

The  Loads  and  Vibrations  System  Command  Sequence,  shown  in  Figure  29,  gen- 
erates loads  and  vibrations  data  for  all  of  the  components  of  the  physical  config- 
uration for  both  steady-state  and  transient  flight  conditions.  The  following 
discussion  of  this  sequence  is  presented  in  the  same  format  as  that  used  in  Sections 
2. 5. 1.1  and  2. 5. 1.2.  Discussion  of  blocks  1 through  7,  9,  10,  and  12  is  omitted 
because  these  blocks  are  identical  to  blocks  1 through  7,  9,  10,  and  12  in  Figure 
28. 

8.  The  Loads  and  Vibrations  Subsequence  receives  input  for  the  response 
and  the  dynamic  characteristics  of  each  component  of  the  physical  configuration. 

It  then  calculates  the  shears,  moments,  stresses,  displacements,  velocities,  and 
accelerations  which  constitute  the  output  sets.  The  calculations  are  performed 
by  subpackages  of  the  Simulation  Model  Subsystem  for  only  those  node  points  at 
which  the  user  requests  output.  The  method  used  depends  upon  the  type  of  dynamic 
model  used  for  the  solution.  Methods  available  include  a direct  approach,  modal 
displacement,  modal  acceleration,  and  an  estimating  procedure  based  on  amplifi- 
cation factors  for  preliminary  design  work. 

11.  The  Loads  and  Vibrations  Subsequence  following  the  Maneuver  Subse-  * 

quence  is  the  same  as  the  subsequence  shown  in  block  8. 

2.5. 1.4  Acoustics  System  Command  Sequence  k 

The  Acoustics  System  Command  Sequence,  shown  in  Figure  30,  is  different  from 
the  three  previously  discussed  sequences  only  with  respect  to  prooess  blocks  8 
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and  11,  which  contain  the  Acoustics  Subsequence.  The  Acoustics  Subsequence 
makes  use  of  the  packages  of  the  Acoustics  Subsystem  to  calculate  the  internal  and 
near-field  and  far-field  sounds  created  by  the  aircraft  configuration.  These  data 
appear  in  the  Acoustic  Field  Data  set.  This  subsequence  represents  several  levels 
of  complexity  consistent  with  the  levels  of  complexity  used  in  the  Simulation  Model 
Subsequence.  Methods  vary  from  purely  empirical  methods  to  considerations  of 
vortex  shedding  and  vortex  interference  effects. 

2. 5. 1. 5 Aeroelastic  Stability  System  Command  Sequence 

The  Aeroelastic  Stability  System  Command  Sequence,  shown  in  Figure  31,  is  dif- 
ferent from  the  four  previously  discussed  sequences  only  in  regard  to  blocks  8 
and  11.  These  blocks  show  the  Aeroelastic  Stability  Subsequence,  which  calculates 
the  Aeroelastic  Stability  Data.  This  set  of  data  includes  aeroelastic  frequencies, 
damping,  and  mode  shapes.  This  process  may  be  performed  by  any  of  three  op- 
tional methods  that  make  use  of  one  of  the  three  packages  of  the  Aeroelastic  Sta- 
bility Subsystem  (i.e. , the  Linear  Aeroelastic  Stability  Analysis  Package,  the 
Floquet  Analysis  Package,  or  the  Aeroelastic  Stability  Postprocessing  Package). 

Because  of  the  similarity  in  structure  of  the  five  System  Command  Sequences,  the 
combination  of  more  than  one  technical  characteristic  in  a single  case  is  possible. 
For  example,  referring  to  Figure  31,  the  Loads  and  Vibrations  Subsequence  may 
be  inserted  before  block  8,  the  Aeroelastic  Stability  Subsequence,  if  the  user 
wishes  to  obtain  loads  and  vibrations  data  as  well  as  aeroelastic  stability  data  for 
a particular  case. 

2.5.2  Details  of  Subsequences 

The  use  of  subsequences  has  been  shown  to  be  an  easily  understood  yet  powerful 
tool  for  solving  engineering  problems.  For  further  understanding  it  is  necessary 
to  see  how  subsequences  are  constructed  and  how  they  function.  One  Trim  Sub- 
sequence and  two  Simulation  Model  Subsequences  are  presented  in  the  following 
subsections  to  convey  this  understanding.  The  Trim  Subsequence  demonstrates 
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how  a complex  logic  network  functions  within  a System.  The  two  Simulation 

Model  Subsequences  show  how  the  various  levels  of  complexity  enter  the  analysis.  , 

2. 5. 2. 1 Trim  Subsequence 

The  Trim  Subsequence  shown  in  Figure  32  shows  the  flow  of  processing  and  data 
for  the  Simultaneous  Iterate-to-Trim  Package  of  the  Trim  Subsystem.  The  proc- 
essing blocks  shown  are  as  follows: 

1.  The  Set  Up  Trim  process  employs  the  user-specified  Trim  Degrees  of 
Freedom  and  Trim  Constraints  sets  to  form  the  steady-state  equations  which  must 
be  solved.  This  includes  fixed  variables,  independent  variables,  and  the  form  and 
number  of  the  equilibrium  equations  to  be  satisfied.  The  primary  result  is  the  Old 
Approximate  Trim  Solution,  from  which  an  improved  solution  is  to  be  generated. 

2.  This  block  indicates  the  top  of  a loop  which  calculates  the  Simulation 
Model  Data  for  several  azimuth  locations  which  represent  one  rotor  revolution. 

When  all  azimuth  locations  have  been  calculated,  control  is  passed  to  block  4 to 
test  for  trim  convergence. 

3.  The  Simulation  Model  Subsequence  calculates  all  of  the  matrix  coeffi- 
cients and  forcing  functions  for  the  equations  of  motion  of  the  configuration.  The 
details  of  this  subsequence  are  discussed  in  Sections  2. 5. 2. 2 and  2. 5. 2. 3 for  two 
different  levels  of  complexity:  preliminary  design  and  detailed  design. 

4.  Block  4 indicates  a test  of  the  Trim  Convergence  Criteria.  This  may 
be  a rather  complicated  set  of  tests,  depending  upon  the  complexity  of  the  aircraft 
configuration.  Therefore,  this  series  of  tests  is  designed  as  a subpackage  which 
sets  a single  parameter  to  be  interrogated  in  the  System  Command  Sequence. 

. ,| 

5.  The  process  of  block  5 is  contained  in  the  same  subpackage  as  block  4. 

f 

When  trim  convergence  is  achieved,  the  Trim  Convergence  Indicator  is  set  to 
TRUE,  and  the  trim  solution  values  are  made  available  for  further  processing* 
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6.  if  the  trim  solution  has  not  converged  at  this  iteration,  the  iteration 
counter  is  incremented,  and  tests  are  made  to  determine  whether  the  maximum 
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number  of  iterations  has  been  exceeded. 

7.  If  the  maximum  number  of  trim  iterations  has  been  exceeded,  the  Trim 
Convergence  Indicator  is  set  to  FALSE.  This  indicates  to  the  Run-Time  Control 

Package  that  the  trim  solution  has  failed.  i 

8.  The  Set  Trim  Error  Vector  Subpackage  sets  an  array  which  is  a meas-  | 

ure,  based  on  the  Simulation  Model  Data  calculated  in  block  3,  of  how  far  the  Old  ] 

Approximate  Trim  Solution  is  from  the  New  Approximate  Trim  Solution.  ‘ 

9.  Block  9 indicates  a test  to  determine  whether  all  of  the  elements  of  the 

Trim  Partial  Derivatives  set  have  been  calculated.  This  is  the  controlling  test  for  ; 

a loop  which  calculates  partial  derivatives  of  forcing  functions  for  each  of  the  in- 
dependent variables. 

10.  This  block  represents  the  Increment  Old  Approximate  Trim  Solution 
Subpackage.  It  makes  prescribed  increments  to  each  of  the  independent  degrees 
of  freedom,  one  at  a time,  as  the  looping  controlled  by  block  9 continues. 

11,  12.  These  two  blocks  again  indicate  an  azimuth  loop  to  calculate  the  Sim- 
ulation  Model  Data  using  both  the  Perturbed  Approximate  Trim  Solution  and  the 
Simulation  Input  Data. 

13.  The  Find  Partial  Derivatives  block  calculates  the  change  in  the  vari- 
ables of  the  Trim  Error  Vector  from  block  12,  minus  the  values  of  the  Trim  Error 
Vector  set  in  block  8,  divided  by  the  increment  to  the  particular  degree  of  free- 
dom, to  obtain  the  Trim  Partial  Derivatives  set. 

14.  The  Nonlinear  Algebraic  Equation  Solution  Package  is  a part  of  the 
General  Mathematical  Operations  Subsystem.  It  is  used  to  generate  a set  of  Trim 
Corrections  to  the  independent  variables  which  leads  to  the  New  Approximate  Trim 
Solution.  Control  then  returns  to  the  top  of  the  subsequence  to  block  2,  where  the 
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New  Approximate  Trim  Solution  (rather  than  the  Old  Approximate  Trim  Solution) 
is  used  as  input  to  the  Simulation  Model  Subsequence. 

2.  5. 2. 2 A Simulation  Model  Subsequence  for  Preliminary  Design 

A Simulation  Model  Subsequence  generates  the  mass,  damping,  and  stiffness  ma- 
trices and  the  forcing  functions  representing  the  aircraft  configuration  and  its 
environment.  The  environment  includes  analysis  components  other  than  the  air- 
craft, such  as  airmass,  wind  tunnel,  test  stand,  and  ground/deck  reference.  A 
Simulation  Model  Subsequence  comprises  System  Commands  which  invoke  sub- 
packages of  the  Simulation  Model  Subsystem.  Because  this  subsequence  is  used 
in  every  System  Command  Sequence,  its  importance  cannot  be  overemphasized. 

Therefore,  a considerable  amount  of  effort  has  been  spent  to  provide  the  user 
with  maximum  flexibility  to  specify  different  types  of  models  while  at  the  same 
time  requiring  him  to  know  very  little  about  the  internal  workings  of  the  System. 

This  provision  results  in  a minimum  amount  of  time  and  effort  in  generating 
models,  in  specifying  solution  requests,  and  in  obtaining  answers.  This  is  par- 
tially accomplished  by  specifying  the  levels  of  complexity  and  the  solution  methods 
in  very  brief  English- language- type  commands.  In  addition,  many  of  the  sub- 
packages used  in  this  subsequence  fall  into  logical  groups  so  that  a single  user 
input  in  the  form  of  a meaningful  keyword  activates  a logical  group  of  subpackages 
which  performs  analysis  for  a single  aircraft  component.  These  logical  groups 
may  be  thought  of  as  sub- subsequences.  t 

The  use  of  such  groups  eliminates  many  of  the  possible  interface  problems  be- 
tween subpackages.  Considering  the  foregoing,  only  a limited  number  of  com- 
monly used  versions  of  the  Simulation  Model  Subsequence  need  be  defined  for  user 
convenience.  It  is  not  necessary  to  have  all  combinations  of  Simulation  Model  Sub- 
sequences  built  into  the  Master  Command  File  because  the  User  Input  Package  has 
the  capability  to  dynamically  build  the  sequence  based  upon  user  input  data.  The 
subsequences  defined  for  user  convenience  include  one  for  preliminary  design  and 
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five  each  for  detailed  design  and  for  research.  These  five  include  common  air- 
craft configurations:  (1)  single-rotor  helicopter,  (2)  tandem-rotor  helicopter, 

(3)  coaxial  helicopter,  (4)  tilt-rotor  aircraft,  and  (5)  test  stand/wind  tunnel  con- 
figuration. 

The  Simulation  Model  Subsequence  for  preliminary  design  is  shown  in  Figure  33. 

The  following  discussion  of  this  sequence  is  presented  in  paragraphs  numbered  to 
correspond  to  the  numbered  blocks  or  dotted  lines  in  the  figure.  Each  of  the  rec- 
tangular processing  blocks  represents  one  of  the  Executive-invocable  subpackages 

of  the  Simulation  Model  Subsystem.  i 

1.  Dotted  line  1 is  a simple  example  of  the  selections  made  by  the  User 

Input  Package  of  the  Executive  Component  in  building  the  Sequence  Control  Table.  ; 

If  the  user  chooses  a single- rotor  helicopter  configuration,  the  Standard  Rigid 
Control  System  Subpackage  is  included  in  the  subsequence  by  the  User  Input  Pack- 
age to  calculate  the  Standard  Rigid  Control  System.  For  other  user-specified  con- 
figurations which  require  more  complex  control  linkages,  the  Generalized  Coupling 
Rigid  Control  System  Subpackage  is  placed  in  the  Sequence  Control  Table  by  the 
User  Input  Package. 

2,  3.  For  the  appropriate  configuration,  one  of  two  subpackages,  i.e. , the 
Standard  Rigid  Control  System  Subpackage  or  the  Generalized  Coupling  Rigid  Con- 
trol System  Subpackage,  computes  the  Control  Settings  set  which  contains  the  local 
control  angles  for  all  controllable  components  (rotors,  aerodynamic  surfaces, 
stores,  or  other). 

4.  The  Rigid  Constant  Speed  Drive  Subpackage  calculates  the  rotational 
speeds  of  all  drive  shafts  by  use  of  a reference  rotational  speed  in  the  Flight  Con- 
ditions set  and  the  geometry  concerned. 

5.  Block  5 calculates  the  Fluid  Flow  Field  in  terms  of  absolute  velocity 
components  at  every  aerodynamic  node  point  in  the  model. 


149 


Figure  33.  Simulation  Model  Subsequence  for  Preliminary  Design 
for  All  Configurations 
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6.  Blocks  6 through  8 represent  one  common  sub-subsequence  which  per- 
forms a complete  rotor  analysis  including  airloads  and  dynamic  response,  in  this  i 

case  for  the  main  or  number  1 rotor.  The  Steady  Aerodynamic  Field  for  a Rotor 

Subpackage  calculates  the  total  velocity  components  of  the  air  relative  to  the  blade 
at  each  aerodynamic  node  on  the  rotor. 

7.  In  block  7 the  aerodynamic  field  is  used  to  find  aerodynamic  coeffi- 
cients and  to  calculate  airloads. 

I 

8.  The  Rigid  Blade  Rotor  Subpackage  evaluates  the  forcing  function  on  the 
rotor  and  calculates  the  time-variant  coefficients  of  the  mass,  damping,  and  stiff- 
ness matrices  representing  the  rotor. 

9.  Dotted  line  9 indicates  another  choice  made  indirectly  by  the  user  and 
directly  by  the  User  Input  Package  in  constructing  the  Sequence  Control  Table. 

For  the  single  rotor  helicopter,  the  antitorque  force  is  supplied  by  the  simple  and 
fast  Semi-Empirical  Rotor  Equations  Subpackage.  For  configurations  with  two 
lifting  rotors,  the  sub-subsequence  shown  in  blocks  11  through  13  is  used  for  the 

< rotor  analysis. 

10.  The  Semi-Empirical  Rotor  Equations  Subpackage  calculates  Rotor 
Forces  and  Moments  for  an  antitorque  tail  rotor. 

11,  12,  13.  Blocks  11  through  13  perform  the  same  function  for  rotor  2 as 
blocks  6 through  8 perform  for  rotor  1. 

» 

14.  The  Steady  Aerodynamic  Coefficients  Using  Bivariant  Table  Subpackage 
evaluates  Fuselage  Airloads  as  a function  of  angle  of  attack  and  sideslip.  The  word 
"fuselage"  at  the  top  of  this  block  indicates  the  aircraft  component  but  is  not  part 
of  the  subpackage  name. 

15.  Block  15  calculates  the  total  Fuselage  Forces  and  Moments  and  the  ele- 
ments of  the  mass,  damping,  stiffhess  matrices  representing  the  fuselage. 
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16.  The  Structural  Coupling  Package  uses  the  previously  general^  forcing 
functions  and  mass,  damping,  and  stiffness  matrices  l»»r  «■.*<  h mhuurmittm  . om- 
ponent  to  generate  the  accelerations  and  the  mass,  damping,  uv  -tiffn.  ss 

i 

matrices  for  the  coupled  configuration. 

2.5.  2.3  A Simulation  Model  Subsequence  lor  l>etail  i •.  «),  ? 

The  tandem-rotor  helicopter  configuration  serve-  «■  hr  . « «•  u t ■ -an  ulntion 
Model  Subsequence  for  detailed  design.  This  subsequent-*,  shows  in  figure  14,  is 
discussed  below  in  paragraphs  numbered  to  correspond  u>  the  numbered  blocks  in 
the  figure. 

1.  The  Automatic  Flight  Control  System  Suhpackage  calculates,  as  a func- 
tion of  stick  or  actuator  motions,  the  forcing  function  and  the  mass,  damping,  and 
stiffness  matrices  representing  the  control  system.  This  analysis  may  be  sensi- 
tive to  airspeed  or  aircraft  angular  motions  as  well  as  other  night  conditions. 

2.  The  Generalized  Coupling  Rigid  Control  System  Subpackage  calculates 
Control  Settings  for  all  rotors,  surfaces,  and  other  components  based  on  the  Con- 
trols Matrix  Elements  from  the  automatic  flight  control  system  and  the  primary 
and  secondary  cockpit  control  positions.  If  a user  desires  to  have  an  elastic  dy- 
namic control  system  representation,  he/she  need  only  supply  the  necessary 
descriptive  Input  data,  and  the  User  Input  Package  automatically  Inserts  the  appro- 
priate System  Commands  in  place  of  block  2 in  this  subsequence. 

3.  The  Detail  Engine  Analysis  Subpackage  calculates  engine  performance 

0 and  the  elements  of  the  mass,  damping,  and  stiffness  matrices  representing  the 

transient  response  for  the  engines. 

4.  The  Table  Look-Up  Flow  Field  Subpackage  uses  a three-  or  four- 
dimensional  table  to  find  rapidly  the  air  velocity  vectors  at  every  aerodynamic  node 
point  on  the  aircraft  or  Its  environment.  This  tabular  representation  of  the  flow 


152 


I 


INPUT 


mocisi 


OUTPUT 


•tnn  V •MtMtAllt’WIVIOUMVf.AtONAtlOOAf* 


Figure  34.  Simulation  Model  Subsequence  for  Detailed  Design  of 
a Tandem-Rotor  Helicopter 


field  would  be  a simplified  model  based  on  more  detailed  calculations  made  during 
another  analysis  run  on  the  System  or  an  independent  computer  program. 


i 

5.  The  Steady  Aerodynamic  Field  for  a Rotor  Subpackage  calculates  the 
relative  velocity  vectors  and  other  variables  which  may  be  required  to  find  the 
steady  airloads  at  the  rotor  nodes. 

6.  The  Unsteady  Aerodynamic  Field  for  a Rotor  Subpackage  calculates 

the  variables  required  to  find  the  unsteady  airloads  at  the  rotor  aerodynamic  node 
points.  * 

7.  The  Steady  Aerodynamic  Coefficients  Using  Trivariant  Table  Subpack- 
age calculates  the  Steady  Airloads  at  the  rotor  aerodynamic  node  points. 

8.  The  Unsteady  Airloads  by  a , A,  B Table  Subpackage  calculates  the 
Unsteady  Airloads  at  the  rotor  aerodynamic  node  points. 

9.  The  Dynamic  Blade  Rotor  with  Hingeless  Hub  Subpackage  calculates 
all  of  the  forcing  functions  and  mass,  damping,  and  stiffness  matrix  coefficients 
for  the  analysis  degrees  of  freedom  for  the  rotor. 

10.  Block  10  indicates  a test  to  determine  whether  the  analysis  for  all 
rotors  has  been  completed.  This  forms  the  end  of  a loop  for  rotor  analysis  which 
encompasses  blocks  5 through  9.  For  a tandem-rotor  helicopter,  this  loop  is  exe- 
cuted twice.  For  helicopters  having  more  than  two  rotors,  the  loop  is  executed 
once  for  each  rotor. 

. 

11,  12,  13,  14.  Blocks  11  through  14  form  a similar  loop  for  aerodynamic 

surfaces.  The  Aerodynamic  Surface  Aerodynamic  Field  is  calculated,  the  Steady  « 

Airloads  are  determined,  and  the  Aerodynamic  Surface  Forces  and  Moments  and 

the  elements  of  the  mass,  damping,  and  stiffness  matrices  representing  the  aero- 

I 

dynamic  surface  are  calculated. 

15.  The  Fuselage  Airloads  are  calculated  by  the  Steady  Aerodynamic  Coef- 
ficients Using  Bivariant  Table  Subpackage. 


154 


f 

) 

t 

I 

1 

p 

16.  The  forcing  function  and  the  elements  of  the  mass,  damping,  and  stiff- 
ness matrices  representing  the  fuselage  are  calculated  based  on  the  Fuselage 
Airloads  and  the  dynamic  coupling  of  the  fuselage  to  each  of  the  rotors  and  aero- 
dynamic surfaces. 

17.  The  Structural  Coupling  Package  uses  the  previously  generated  forcing 
functions  and  mass,  damping,  and  stiffness  matrices  for  each  configuration  com- 
ponent to  generate  the  accelerations  and  the  mass,  damping,  and  stiffness  matrices 

* for  the  coupled  configuration. 
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The  System's  analysis  capability  to  accurately  predict  helicopter  performance, 
stability  and  control,  loads  and  vibrations,  acoustics,  and  aeroelastic  stability 
for  a variety  of  aircraft  configurations  is  needed  during  three  aircraft  life  cycle 
phases:  preliminary  design,  detailed  design,  and  research.  In  addition,  the  * 

System  must  also  provide  functional  capabilities  which  are  secondary  to  the  pri- 
mary analysis  function  of  the  System.  These  secondary  functional  capabilities 

t 

are  necessary  to  ensure  that  the  System  is  general-purpose,  user-oriented,  trans- 
portable, extendable,  maintainable,  and  efficient.  These  secondary  functional 
capabilities  are  identified  as  executive/support  capabilities  in  the  remainder  of 
this  section. 

Two  releases  of  the  System  are  planned  during  the  Development  Phase:  the  First 
Level  Release  and  the  Second  Level  Release.  The  functional  requirements  to  be 
satisfied  by  each  release  are  specified  in  the  Baseline  Type  A System  Specifica- 
tion. CSC  and  BHT  have  synthesized  a design  which  defines  a software  system 
which  satisfies  the  requirements  of  both  System  releases  and  establishes  a firm 
foundation  on  which  future  capabilities  can  be  built. 

Table  2 identifies  the  System  release  which  provides  the  required  analysis  capa-  k ' 

bill  ties  for  each  required  aircraft  life  cycle  phase,  "pie  detailed  capabilities 

planned  for  inclusion  in  the  First  Level  Release  and  the  Second  Level  Release  sure 

identified  in  Sections  3.1  and  3.2,  respectively.  For  each  release,  the  detailed 

analysis  capabilities  are  presented  first,  followed  by  the  detailed  executive/support 

( 

capabilities. 

3.1  FIRST  LEVEL  RELEASE 

« 

As  indicated  in  Table  2,  the  First  Level  Release  of  the  System  provides  a com- 
plete set  of  capabilities  for  the  preliminary  design  and  detailed  design  aircraft 
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Table  2.  Achievement  of  Aircraft  Technical  Characteristic  and  Life 
Cycle  Phase  Analysis  Capabilities  in  the  First  and 
Second  Level  System  Releases 


LIFE  CYCLE  PHASE 

TECHNICAL 

CHARACTERISTICS 

PRELIMINARY 

DESIGN 

DETAILED 

DESIGN 

1 

RESEARCH 

PERFORMANCE 

1 

1 

2 

STABILITY  AND  CONTROL 

1 

1 

2 

LOADS  AND  VIBRATIONS 

ROTOR  LOADS 

1 

1 

2 

AIRFRAME  LOADS 

2 

2 

2 

ENGINE/DRIVE  SYSTEM  LOADS 

2 

2 

2 

CONTROL-SYSTEM/PILOT  LOADS 

2 

2 

2 

ACOUSTICS 

1 

2 

2 

AEROELASTIC  STABILITY 

1 

1 

2 

1 
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life  cycle  phases  to  analyze  the  following  technical  characteristics  of  a rotary- 
wing configuration:  performance,  stability  and  control,  rotor  loads  and  vibrations, 
and  aeroelastic  stability.  The  First  Level  Release  also  provides  a complete  pre- 
liminary design  acoustics  analysis  capability  and  an  extensive  set  of  executive/ 
support  capabilities  which  ensure  that  the  First  Level  Release  of  the  System  is 
general-purpose,  user-oriented,  transportable,  extendable,  maintainable,  and 
efficient.  The  principal  differences  between  the  executive/support  capabilities  in 
the  First  Level  Release  and  those  in  the  Second  Level  Release  are  the  computers 
on  which  the  System  is  available,  the  amount  of  interactive  interface,  and  the 
scope  of  cost  assessment.  The  First  Level  Release  is  planned  to  be  initially 
available  on  IBM  S/370  and  S/360  computers.  However,  the  design  makes  possible 
the  availability  of  the  First  Level  Release  capability  on  CDC  6000  and  CYBER  se- 
ries of  computers  4 months  after  its  availability  on  the  IBM  S/370  and  S/360 
computers.  The  Second  Level  Release  is  planned  to  be  available  on  both  computer 
families. 

The  First  Level  Release  has  an  interactive  capability  permitting  the  user  to  pre- 
pare input  data  and  to  inspect  analysis  results  at  an  interactive  terminal;  the 
Second  Level  Release  provides,  in  addition,  an  interactive  tutorial  capability  and 
an  interactive  analysis  capability.  Finally,  the  First  Level  Release  provides  cost 
estimates  at  the  conclusion  of  an  analysis  run,  whereas  the  Second  Level  Release 
also  provides  cost  estimates  before  execution  of  an  analysis. 

Section  3. 1. 1 presents  the  detailed  analysis  capabilities  provided  by  the  First 
Level  Release.  Section  3. 1.2  presents  the  detailed  executive/support  capabilities 
provided  by  the  First  Level  Release. 

3. 1. 1 First  Level  Release  Analysis  Capabilities 

To  provide  preliminary  design  and  detailed  design  analysis  capabilities  for  per- 
formance, stability  and  control,  rotor  loads  and  vibrations,  aeroelastic  stability, 
and  acoustics  (preliminary  design  only)  in  the  First  Level  Release,  the  System 
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The  First  Level  Release  provides  the  capability  to  generate  finite  element  rep- 
resentations of  rotors,  generalized  rigid  control  systems,  engine/drive  systems, 
airframes,  an  airmass,  ground/deck  surfaces,  and  test  stands.  Three  types  of 
rotor  representations  are  included:  semiempirical  equation  representations,  rigid 
blade  equation  representations,  and  dynamic  analysis  representations  (with  lag 
dampers,  flapping  stops,  and  lag  stops)  for  all  hub  types.  The  engine/drive  system 
representations  include  both  rigid  and  static  elastic  representations  using  engine 
performance  tables.  Airframe  component  representations  include  a rigid  fuselage, 
aerodynamic  surfaces,  stores,  pylons,  and  a simple  landing  gear.  The  airmass 
representations  include  steady  aerodynamics  using  tables,  unsteady  aerodynamics 
using  Theodorsen/Loewy  or  a.  A,  B methods,  momentum  theory  flow  fields  with 
or  without  time  delay,  and  prescribed  rotor  wakes.  The  First  Level  Release  also 
includes  a general,  systematic,  and  accurate  method  for  coupling  rotating  and 
nonrotating  components  which  employs  a minimum  number  of  degrees  of  freedom, 
which  permits  individual  components  to  be  independently  analyzed,  and  which  is 
compatible  with  results  generated  by  the  test  procedures  used  throughout  the  heli- 
copter industry.  The  specific  analysis  capabilities  to  be  included  in  the  First 
Level  Release  are  identified  in  subsequent  subsections  in  terms  of  the  analysis 
capabilities  provided  by  each  of  10  subsystems  of  the  Technology  Component. 

3. 1. 1. 1 Simulation  Model  Initialization 

The  Simulation  Model  Initialization  Subsystem  establishes  the  local  (i.e. , compo- 
nent) and  global  (1.  e. , configuration)  coordinate  systems  and  generates  both  the 
initial  vector  of  forcing  functions  and  the  constant  coefficients  of  each  component’s 
mass,  damping,  and  stiffness  matrices.  For  the  First  Level  Release,  the  Simu- 
lation Model  Initialization  Subsystem  provides  the  capability  to  define  components 
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in  component  local  coordinate  systems,  define  the  coordinate  system  of  the 
coupled  configuration,  assemble  the  initial  vector  of  forcing  functions,  and  gen- 
erate the  constant  coefficients  in  the  mass,  damping,  and  stiffness  matrices  for 
the  component  representations  identified  in  Section  3. 1. 1.  In  addition,  all  user- 
supplied  input  data  are  checked  for  reasonableness  and  for  potential  effects  on 
numerical  stability.  Specific  First  Level  Release  analysis  capabilities  provided 
by  the  Simulation  Model  Initialization  Subsystem  are  listed  below,  together  with 
the  software  elements  which  provide  the  capabilities. 

* 

Capability  Software  Element 


Calculate  constant  coefficients  for  the 
rotor,  the  airframe,  the  engine/drive 
system,  and  generalized  rigid  control 
system  models 

Calculate  constant  coefficients  for  the 
airmass,  test  stand,  and  ground/deck 
models 

Combine  the  aircraft  and  environment 
models  and  verify  the  compatibility  of 
the  aircraft  and  environment  models 

Set  up  coordinate  systems  and  trans- 
formations for  all  components 

Assemble  mass,  damping,  and  stiff- 
ness matrices  for  a rotor  in  terms  of 
node  point  displacements 

Compute  the  natural  frequencies  and 
the  normalized  mode  shapes  for  a rotor 

Compute  initial  estimates  of  the  rotor 
wake  geometry  and  the  wake  element 
influence  coefficients 

3. 1. 1. 2 Simulation  Modeling 


Combine  Aircraft  Components 
Package 


Combine  Environment  Components 
Package 

Combine  Aircraft  and  Environment 
Components  Package 

Coordinate  Systems  and  Transfor- 
mations Package 

Rotor  Finite  Element  Initialization 
Package 

Rotor  Modes  Package 
Wake  Initialization  Package 


The  Simulation  Model  Subsystem  uses  the  computed  results  of  the  Simulation 
Model  Initialization  Subsystem  to  calculate  forcing  functions  and  coupling 
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coefficients  for  the  equations  of  motion,  the  distributed  aerodynamic  loads  and 

vibrations  data,  and  the  aerodynamic  forces  and  moments  on  each  aircraft  com-  i 

ponent.  The  specific  simulation  modeling  capabilities  to  be  provided  in  the  First 
Level  Release  are  presented  in  terms  of  each  analysis  component.  This  subsys- 
tem also  provides,  in  the  First  Level  Release,  the  component  coupling  capability 
of  the  System. 

3.1. 1.2. 1 Rotor 

The  rotor  simulation  modeling  capabilities  to  be  included  in  the  First  Level  Re- 
lease are  listed  below,  together  with  the  software  elements  which  provide  the  ' 

capabilities. 


Capability 

Compute  rotor  hub  forces  and  moments 
by  interpolation  from  a table 

Compute  approximate  rotor  performance 
using  simple  equations 

Compute  approximate  ducted-fan  per- 
formance using  simple  equations 

Calculate  the  matrix  elements  and 
forcing  function  representing  an  inelas- 
tic rotor 

Calculate  the  matrix  elements  and 
forcing  function  representing  an  elastic 
rotor  with  a teetering  or  gimbaled  hub 

Calculate  the  matrix  elements  and 
forcing  function  representing  an  elastic 
rotor  with  an  articulated  hub 

Calculate  the  matrix  elements  and 
forcing  function  representing  an  elastic 
rotor  with  a hingeless  hub 

Calculate  the  matrix  elements  and 
forcing  function  representing  an  elastic 
rotor  with  a bearingless  hub 


Software  Element 


Rotor  Map  Subpackage 

Semi-Empirical  Rotor  Equations 
Subpackage 

Semi-Empirical  Ducted  Fan  Sub- 
package 

Rigid  Blade  Rotor  Subpackage 


Dynamic  Blade  Rotor  with  Teeter- 
ing/Gimbaled  Hub  Subpackage 

Dynamic  Blade  Rotor  with  Articu- 
lated Hub  Subpackage 

Dynamic  Blade  Rotor  with  Hingeless 
Hub  Subpackage 

Dynamic  Blade  Rotor  with  Bearing- 
less Hub  Subpackage 
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Capability  Software  Element 


Compute  rotor  shears,  moments,  accel- 
erations, velocities,  and  displacements 
from  the  calculated  response 

Rotor  Loads  and  Vibrations  Sub- 
package 

Compute  for  each  aerodynamic  node 
point  the  relative  velocity  components 
of  the  air  with  respect  to  the  rotor,  the 
angle  of  attack,  the  yawed  flow  angle, 
the  Mach  number,  and  the  Reynolds  num- 
ber 

Steady  Aerodynamic  Field  for  a 

Rotor  Subpackage 

% 

Compute  for  each  aerodynamic  node 
point  the  first  and  second  time  deriva- 
tives of  the  angle  of  attack 

Unsteady  Aerodynamic  Field  for  a 
Rotor  Subpackage 

Compute  the  loads  imparted  to  the  rotor 
by  a viscous  or  hydraulic  lag  damper 

Viscous/Hydraulic  Lag  Damper 
Subpackage 

Compute  the  loads  imparted  to  the  rotor 
by  an  elastomeric  lag  damper 

Elastomeric  Lag  Damper  Subpack- 
age 

Compute  the  loads  transmitted  to  the 
mast,  hub,  and/or  blade  by  flapping  stop 
contact 

Rotor  Flapping  Stops  Subpackage 

Compute  the  loads  transmitted  to  the 
mast,  hub,  and/or  blade  by  lag  stop  con- 
tact 

Rotor  Lag  Stops  Subpackage 

3. 1. 1. 2.  2 Control  System/Pilot 

1 

The  control  system/pilot  simulation  modeling  capabilities  to  be  included  in  the 

First  Level  Release  are  listed  below,  together  with  the  software  elements  which 

r 

provide  the  capabilities. 

4 

Capability 

Software  Element 

Provide  all  riggings  for  a standard  single 
rotor  helicopter  control  system 

Standard  Helicopter  Rigid  Control 
System  Subpackage 

0 
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Capability 


Software  Element 


Provide  all  riggings  for  primary  cockpit  Generalized  Coupling  Rigid  Control 

controls  of  unconventional  rotorcraft  System  Subpackage 

(tandem,  tilt- rotor,  etc.) 

Activate  secondary  cockpit  controls  Auxiliary  Controls  Subpackage 

3.1. 1.2.3  Engine/Drive  System 

The  engine/drive  system  simulation  modeling  capabilities  to  be  included  in  the 
First  Level  Release  are  listed  below,  together  with  the  software  elements  which 
provide  the  capabilities. 


Capability 


Compute  the  rotational  speeds  and  gear- 
box losses  for  all  components  of  the  drive 
system 

Compute  engine  performance  parameters 
using  a table  lookup  procedure 

Calculate  the  stiffness  matrix  elements 
representing  flexible,  but  not  dynamic, 
drive  shaft 


Software  Element 


Rigid  Drive  System/Constant 
Speed  Analysis  Subpackage 

Engine  Performance  Table  Sub- 
package 

Static  Elastic  Drive  Shaft  Subpack- 
age 


3.1. 1.2.4  Airframe 

The  airframe  simulation  modeling  capabilities  to  be  included  in  the  First  Level 
Release  are  listed  below,  together  with  the  software  elements  which  provide  the 
capabilities. 


Capability Software  Element 

Define  user-specified  test  stand  motions  Prescribed  Motion  Test  Stand  Sub- 

package 

Calculate  the  matrix  elements  and  the  Rigid  Two-dimensional  Fuselage 

applied  external  forcing  functions  repre-  Subpackage 
senting  a fuselage  with  three  rigid-body 
degrees  of  freedom 
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Capability 


Calculate  the  matrix  elements  and  the 
applied  external  forcing  functions  repre- 
senting a fuselage  with  six  rigid-body 
degrees  of  freedom 

Calculate  the  matrix  elements  and  forcing 
function  representing  a rigid  pylon 

Compute  the  velocity  components,  angle 
of  attack,  sideslip  angle,  Mach  number, 
and  Reynolds  number  for  an  aerodynamic 
surface 

Calculate  mass  matrix  elements  repre- 
senting rigid  aerodynamic  surfaces  and 
compute  the  forces  and  moments  trans- 
mitted from  the  surfaces  to  the  airframe 

Calculate  the  stiffness  matrix  elements 
and  forcing  function  representing  a flexi- 
ble nondynamic  landing  gear 

Calculate  the  matrix  elements  and  the 
aerodynamic  forcing  function  represent- 
ing rigid  stores  which  are  either  fuselage- 
mounted  or  wing-mounted 

Calculate  the  mass  matrix  elements  and 
the  forcing  function  representing  rigid- 
body  internal  cargo 

3. 1.1. 2. 5 Airmass 


Rigid  Three-dimensional  Subpack- 
age 


Rigid  Pylon  Subpackage 

Aerodynamic  Field  for  an  Aerody- 
namic Surface  Subpackage 


Rigid  Aerodynamic  Surface 
Subpackage 


Simple  Landing  Gear  Subpackage 


Rigid  Stores  Subpackage 


Internal  Cargo  Subpackage 


The  airmass  simulation  modeling  capabilities  to  be  Included  in  the  First  Level 
Release  are  listed  below,  together  with  the  software  elements  which  provide  the 
capabilities. 


Capabilit 


Compute  aerodynamic  coefficients  using 
simple  equations 


Software  Element 

Steady  Aerodynamic  Coefficients 
Using  Simple  Equations  Subpack- 
age 
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Capability 

Extract  aerodynamic  coefficients  from  a 
two-dimensional  table 

Extract  aerodynamic  coefficients  from  a 
three-dimensional  table 

Extract  aerodynamic  coefficients  from  a 
four-dimensional  table 

Compute  unsteady  aerodynamic  coeffi- 
cients and  airloads  using  the  combined 
theories  of  Theodorsen  and  Loewy 

Extract  unsteady  aerodynamic  coeffi- 
cients from  the  (a  , A , B)  table  and 
compute  the  unsteady  airloads 

Compute  the  induced  velocity  distribution 
on  an  aerodynamic  surface,  neglecting 
unsteady  effects 

Compute  the  induced  velocity  distribution 
on  an  aerodynamic  surface,  including 
first-order  unsteady  effects 

Compute  the  induced  velocity  field  due  to 
a prescribed  wake  geometry 

Compute  the  modifications  to  airfoil  sec- 
tion properties  due  to  flap  extension 

Compute  the  modifications  to  airfoil  sec- 
tion properties  due  to  spoiler  extension 

3. 1. 1. 2. 6 Ground/Deck  Surface 


Software  Element 


Steady  Aerodynamic  Coefficients 
Using  Bivariant  Table  Subpackage 

Steady  Aerodynamic  Coefficients 
Using  Trivariant  Table  Subpackage 

Steady  Aerodynamic  Coefficients 
Using  Quadrivariant  Table  Sub- 
package 

Unsteady  Airloads  by  Theodorsen/ 
Loewy  Theory  Subpackage 

Unsteady  Airloads  by  a , A , B 
Table  Subpackage 

Momentum  Theory  Flow  Field 
Subpackage 

Momentum'  Theory  Flow  Field  with 
Time  Delay  Subpackage 

Prescribed  Wake  Subpackage 

Flap  Aerodynamic  Coefficients 
Subpackage 

Spoiler  Aerodynamic  Coefficients 
Subpackage 


The  ground/deck  simulation  modeling  capabilities  to  be  included  in  the  First  Level 
Release  are  listed  below,  together  with  the  software  elements  which  provide  the 
capabilities. 


Capability  Software  Element 

Compute  the  relative  motion  between  the  Prescribed  Motion  Ground /Deck 

aircraft  and  a planar,  rigid  ground/deck  Surface  Subpackage 


i 
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Capability 


Software  Element 


surface  undergoing  arbitrary  user- 
prescribed  motion  and  contact-dependent 
forces 

Compute  the  relative  motion  between  the 
aircraft  and  a rigid,  two-dimensional 
ground/deck  surface  undergoing  simple 
user-prescribed  motion  and  contact- 
dependent  forces 

Compute  the  relative  motion  between  the 
aircraft  and  a rigid,  three-dimensional 
ground/deck  surface  undergoing  simple 
user-prescribed  motion  and  contact- 
dependent  forces 

3. 1. 1. 2. 7 Coupling  of  Components 

A capability  to  couple  independently  defined  configuration  components  is  included 
in  the  First  Level  Release.  The  component  coupling  capability  transforms  the 
individual  component  forcing  functions  and  component  mass,  damping,  and  stiff- 
ness matrices  into  a single  forcing  function  and  a single  mass,  damping,  and 
stiffness  matrix  representing  the  coupled  configuration.  The  mathematical  tech- 
nique employed  is  defined  in  Section  2. 1 of  this  report.  The  component  coupling 
capability  is  provided  by  the  Structural  Coupling  Package  in  the  Simulation  Model 
Subsystem.  This  software  element  also  calculates  the  global  acceleration  vector 
based  on  the  coupled  configuration  and  derives  from  it  the  local  acceleration  vec- 
tor for  each  component. 

3. 1.1.3  Trim 

Two  alternative  trim  solution  capabilities  will  be  provided  in  the  First  Level  Re- 
lease. These  capabilities,  together  with  the  software  elements  which  provide 
them,  are  listed  below. 


Two-dimensional  Ground/Deck 
Surface  Subpackage 


Three-dimensional  Ground/Deck 
Surface  Subpackage 


Capabilii 


Software  Element 


r 


Iterate  all  trim  equations  to  find  a steady-  Simultaneous  Iterate -to-Trim 
state  condition  Package 

Use  autopilot  to  simulate  flight  to  a Fly-to-Trim  Package 

steady-state  condition 


3. 1. 1. 4 Maneuvers 

Two  alternative  capabilities  are  provided  in  the  First  Level  Release  to  calculate 
control  motion  disturbances  for  transient  solutions.  These  capabilities,  together 
with  the  software  elements  which  provide  them,  are  listed  below. 

Capability Software  Element 


Calculate  time-dependent  control  posi- 
tions from  user-specified  control  mo- 
tions 

Calculate  control  motions  required  to 
follow  a user-specified  aircraft  response 

3. 1. 1. 5 Stability  and  Control 


Prescribed  Control  Motions  Pack- 
age 

Prescribed  Aircraft  Response 
Package 


The  complete  stability  and  control  analysis  capability  is.  included  in  the  First 
Level  Release.  The  detailed  capabilities  needed  to  calculate  stability  and  control 
data  are  listed  below,  together  with  the  software  elements  which  provide  the  de- 
tailed capabilities. 

Capability Software  Element 


Calculate  stability  derivatives  and  gen- 
erate linearized  equations  of  motion 

Calculate  eigenvalues  and  eigenvectors 
for  stability  and  control 

Calculate  stability  and  control  transfer 
functions  and  frequency  response  for 
selected  control  inputs 


Linearized  Equations  for  Stability 
and  Control  Package 

Stability  Eigenvalues  and  Eigen- 
vectors Package 

Transfer  Functions  and  Frequency 
Response  Package 
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A capability  to  calculate  an  empirical  noise  field,  including  the  effects  of  noise 
dissipation  and  noise  reflection,  is  provided  by  the  Sound  Propagation  Package  in 
the  First  Level  Release. 


3. 1. 1. 7 Aeroelastic  Stability 

Three  alternative  aeroelastic  stability  analysis  capabilities  will  be  provided  in  the 
First  Level  Release.  These  capabilities  are  listed  below,  together  with  the  soft- 
ware elements  which  provide  the  capabilities. 

Capability Software  Element 

Calculate  stability  frequencies  and  damp-  Linear  Aeroelastic  Stability  Analy- 
ing  coefficients  by  eigenanalysis  of  sis  Package 

linearized  equations 

Calculate  stability  frequencies  and  Floquet  Analysis  Package 

damping  coefficients  for  equations  with 
periodic  coefficients 

Calculate  stability  frequencies  and  damp-  Aeroelastic  Stability  Postproc- 
ing  coefficients  by  processing  time  his-  essing  Package 

tory  data 

3. 1. 1. 8 General  Mathematical  Operations 


All  general  mathematical  operation  capabilities  needed  to  support  First  Level 
Release  and  Second  Level  Release  analysis  capabilities  are  provided  as  part  of 
the  First  Level  Release.  All  included  matrix  manipulation  capabilities  accept 
matrices  which  exceed  the  size  of  computer  memory  available  to  the  System  (l.e. , 
perform  operations  on  data  residing  in  whole  or  In  part  on  peripheral  storage). 

The  general  mathematical  operation  capabilities  are  listed  below,  together  with 
the  software  elements  which  provide  the  capabilities. 


Solve  a set  of  linear  equations  with  real 
or  complex  coefficients 


Software  Element 

Linear  Algebraic  Equation  Solution 
Package 
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Software  Element 
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Solve  a set  of  nonlinear,  first-order, 
stiff,  or  nonstiff  ordinary  differential 
equations 

Determine  the  eigenvalues  and  eigen- 
vectors for  real  general,  complex 
general,  complex  Hermitian,  and  real 
symmetric  matrices 

Compute  the  first  and  second  derivatives 
of  a tabular  function 

Multiply  and/or  add  two  real  or  complex 
matrices 

Perform  a general  harmonic  analysis  of 
a given  time  history 

Invert  square,  nonsingular,  real  or  com- 
plex matrices 

Compute  the  frequency  content  and  asso- 
ciated damping  c£  a given  time  history  by 
using  a moving-block  Fast  Fourier  Trans- 
form . 

Transform  a three-component  vector  from 
one  orthogonal  coordinate  system  to 
another 

Compute  autocorrelation  and  cross- 
correlation functions  for  given  time  his- 
tories 

Decompose  nonsingular,  square  matrices 

Perform  a linear,  cubic,  or  bicubic  inter- 
polation or  extrapolation  of  a function 

Solve  sets  of  nonlinear  equations 

Integrate  a real  function  over  a closed 
interval 


Differential  Equation  Solution  Pack- 
age 

Eigenvalue/Eigenvector  Package 


Numerical  Differentiation  Package 

Matrix  Multiplication  and  Addition 
Package 

Harmonic  Analysis  Package 

Matrix  Inversion  Package 

Moving-Block  Fast  Fourier  Trans- 
form Package 


General  Coordinate  Transforma- 
tion Package 

Statistical  Functions  Package 

Matrix  Decomposition  Package 

Interpolation/Extrapolation  Pack- 
age 

Nonlinear  Algebraic  Equations 
Solution  Package 

Quadrature  Package 
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Capability Software  Element 

Compute  the  frequency  content  and  asso-  Prony's  Method  Harmonic  Curve 

ciated  damping  of  a given  time  history  Fit  Package 

by  using  Prony’ s Method 

3. 1. 1. 9 External  Models  Interface 

One  software  element  (External  Model  1 Package)  is  included  in  the  First  Level 
Release  to  provide  an  interface  from  the  System  to  one  Government-specified  ex- 
ternal model.  The  specific  external  model  has  not  yet  been  specified.  v 

3. 1. 1. 10  Accuracy  Assessment 

No  accuracy  assessment  capability  is  planned  for  the  First  Level  Release. 

3.1.2  First  Level  Release  Executive/Support  Capabilities 

Virtually  all  executive/support  capabilities  specified  for  inclusion  in  the  Second 
Level  Release  are  included  in  the  First  Level  Release  as  well.  There  are  five 
categories  of  executive/support  capabilities  included  in  both  releases:  user  inter- 
face, run-time  management,  data  base  management,  operating  system  services, 
and  support  services. 

3. 1. 2. 1 User  Interface 

The  user  interface  capabilities  planned  for  inclusion  in  the  First  Level  Release 
will  facilitate  the  use  of  the  System  by  both  engineering  users  and  methods  devel- 
opers. The  following  is  a list  of  user  interface  capabilities  to  be  included  in  the 
First  Level  Release: 

4 

1.  An  interface  between  the  engineering  user  and  the  System  is  defined 
which  allows  the  user  to  analyze  a problem  without  requiring  the  user 

to  understand  the  software  design  of  the  System.  4 

2.  The  user  does  not  need  to  specify  the  sequence  of  execution  for  analy- 
sis software  elements — the  execution  sequence  will  be  automatically 
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defined  by  the  System  based  upon  the  characteristics  of  the  configura- 
tion to  be  analyzed,  the  type  of  analysis  desired,  and  the  level  of  de- 
tail (i.e.,  aircraft  life  cycle  phase:  preliminary  design,  detailed 
design,  or  research)  at  which  the  configuration  is  to  be  analyzed. 

The  user  can  define  the  configuration  to  be  analyzed  in  terms  of  any 
combination  of  component  models  previously  stored  in  a Master  Data 
Base  and  component  models  defined  by  the  user  at  analysis  run  time. 

If  the  user  wishes  to  define  a modified  version  of  a component  model 
which  resides  in  a Master  Data  Base,  only  the  modifications  need  be 
specified  at  analysis  run  time. 

A simple  high-level  System  Command  Language  is  available  if  the  user 
wishes  to  explicitly  control  the  execution  sequence  of  analysis  software 
elements. 

A Master  Command  File,  containing  validated  sets  of  System  Com- 
mand Sequences  needed  to  use  the  particular  functional  capabilities 
provided  by  the  First  Level  Release,  will  be  provided  to  all  users  of 
the  First  Level  Release. 

Frequently  used  sets  of  System  Commands  can  be  stored  by  authorized 
users  (either  engineering  users  or  methods  developers)  in  a Master 
Command  File  for  subsequent  use. 

The  user  may  construct  a complete  sequence  of  System  Commands  by 
specifying  any  combination  of  predefined  sets  of  System  Command 
Sequences  residing  on  a Master  Command  File  and  command  sequences 
defined  by  the  user  at  analysis  run  time. 

If  the  user  wishes  to  define  a modified  version  of  a System  Command 
Sequence  which  resides  on  a Master  Command  File,  only  modifications 
need  be  specified  at  analysis  run  time. 


10.  User  input  data  can  be  provided  either  in  the  form  of  a deck  of  cards 
or  in  the  form  of  a card  image  file  prepared  at  an  interactive  termi- 
nal. 

11.  Printed  reports  of  all  input  explicitly  supplied  by  the  user  are  gen- 
erated. 

12.  If  desired,  printed  reports  of  all  input  implicitly  supplied  by  the  user 
(i.e. , component  models  extracted  from  a Master  Data  Base,  includ- 
ing all  user- specified  modifications  and  System  Command  Sequences 
extracted  from  a Master  Command  File,  including  all  user- specified 
modifications)  are  generated. 

13.  All  user-specified  input  data  are  inspected  for  actual  or  possible 

% 

errors.  All  resulting  diagnostic  messages  are  reported  using  clear 
and  concise  engineering-oriented  terminology. 

14.  Component  and  configuration  model  definition  data  can  be  plotted. 

15.  Analysis  results  may  be  output  as  printed  reports,  plots,  or  combina- 
tions thereof. 

16.  Multiple  formats  of  printed  reports  and  plots  are  provided  so  that  the 
user  can  select  the  most  meaningful  format  for  inspecting  analysis 
results. 

17.  All  reports  generated  by  t le  System  are  available  for  inspection  at  an 
interactive  terminal. 

3. 1. 2. 2 Run-Time  Management 

The  purpose  of  the  run-time  management  capability  is  to  supervise  the  processing 
that  takes  place  during  an  analysis  run.  All  run-time  management  capabilities 
needed  for  the  Second  Level  Release  are  planned  to  be  included  in  the  First  Level 
Release  as  well.  Run-time  management  capabilities  are  particularly  important 
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from  two  aspects:  efficiency  and  extendability.  Capabilities  are  provided  to  mini- 
mize the  costs  of  analyzing  both  small  and  large  problems  and  to  facilitate  ex- 
perimentation with  new  or  modified  analysis  capabilities.  The  following  is  a list 
of  detailed  run-time  management  capabilities  to  be  provided  by  the  First  Level 
Release: 

1.  Memory,  CPU,  and  device  utilization  statistics  are  collected  as  each 
analysis  software  element  is  executed.  (These  statistics  can  be  used 
to  assess  the  performance  impact  of  new  or  modified  analysis  capa- 
bilities. ) 

2.  Linkage  overhead  is  minimized  by  grouping  related  software  elements 
into  load-modules.  (This  permits  a direct  call  between  software  ele- 
ments rather  than  the  more  costly  indirect  linkage  through  either  an 
Executive  or  operating  system  service. ) 

3.  Inactive  load-modules  are  not  deleted  from  memory  until  the  memory 
is  needed  for  other  load-modules  or  for  data.  (This  avoids  potentially 
unnecessary  overhead  needed  to  reload  load -modules. ) 

4.  All  available  memory  other  than  the  memory  required  by  active  load- 
modules  is  used,  if  needed,  for  the  data  required  by  the  active  load- 
modules.  (This  minimizes  the  amount  of  I/O  overhead  incurred  by 
small  problems. ) 

5.  Memory-resident  data  are  not  output  to  a peripheral  device  unless  the 
memory  is  needed  for  additional  data  by  another  load-module.  (This 
minimizes  the  amount  of  I/O  overhead  incurred  by  small  problems. ) 

6.  If  the  user  wishes  to  define  a new  sequence  of  System  Commands  that 
use  already  existing  software  elements,  no  software  modifications  are 
necessary  and  no  load-modules  need  be  rebuilt.  (The  run-time 
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management  function  controls  the  sequence  of  software  element  exe- 
cutions based  on  System  Commands,  i.e. , the  sequence  of  software 
element  executions  is  not  defined  in  a software  element. ) 

7.  A software  element  can  generate  System  Commands  to  accomplish  its 
function.  (This  typically  is  used  when  a software  element,  in  order 
to  accomplish  its  designated  function,  must  use  a function  provided 
by  a different  software  element. ) 

8.  Meaningful  diagnostics  describing  internal  software  problems  are 
provided,  along  with  the  corresponding  information  needed  to  identify 
the  cause  of  the  problem. 

9.  An  analysis  run  can  be  restarted,  following  an  unexpected  termination 
or  normal  completion,  with  modified  model  data  or  a modified  se- 
quence of  System  Commands.  (This  avoids  unnecessary  repetition  of 
analysis  processing. ) 

10.  Restart  information  generated  by  an  analysis  run  can  be  used  by  any 

subsequent  analysis  run.  (This  avoids  recalculating  information  which 
would  be  otherwise  unaffected  by  the  analysis  performed  in  the  subse- 
quent analysis  run,  e.g. , the  stiffness,  mass,  or  damping  matrix 
representing  a component  common  to  multiple  aircraft  configurations. ) 

3. 1. 2. 3 Data  Base  Management 

The  complete  data  base  management  capability  is  included  in  the  First  Level  Re- 
lease. The  data  base  management  capability  is  specially  designed  to  meet  the 
efficiency  and  extendability  needs  of  the  Second  Generation  Comprehensive  Heli- 
copter Analysis  System.  The  following  list  summarizes  the  data  base  management 
capabilities  provided  in  the  System: 

1.  Data  base  storage  and  retrieval  services  are  provided,  which  elimi- 
nate the  need  for  a software  element  to  consider  the  location  or 
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organization  of  the  data;  i.e. , data  are  requested  by  name  rather  than 
by  relative  location.  (This  approach  also  allows  part  or  all  of  the 
data  base  to  be  memory  resident,  depending  on  problem  size,  without 
affecting  the  logical  operation  of  a software  element. ) 

2.  At  analysis  run  initiation,  a special  run-time  data  base  is  formed  con- 

i 

taining  only  the  Master  Data  Base  information,  as  augmented  by  user 
data,  needed  to  perform  the  analysis.  (This  reduces  the  size  of  the 
« data  base  needed  for  the  analysis,  thus  reducing  data  access  over- 

head. ) 

3.  Modifications  to  a Master  Data  Base  and  Master  Command  File  are  not 
permitted  during  an  analysis  run.  (This  allows  a user  installation  to 
establish  controlled  procedures  for  updating  a Master  Data  Base  and  a 
Master  Command  File.) 

4.  Support  capabilities  are  provided  to  modify  a Master  Data  Base  and  a 
Master  Command  File  and  to  generate  output  reports  describing  the 
contents  thereof. 

5.  Frequently  used  component  model  data  and  System  Command  Sequences 
can  be  stored  in  a Master  Data  Base  and  a Master  Command  File, 
respectively.  (This  permits  the  inclusion  of  the  component  models 
and  command  sequences  in  subsequent  analysis  runs  without  respeci- 
fying the  detailed  model  data  or  the  System  Commands. ) 

3. 1. 2. 4 Operating  System  Services 

The  operating  system  services  provided  by  the  System  are  designed  to  facilitate 
transportability.  For  the  First  Level  Release,  the  services  will  be  provided  for 
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IBM  S/370  and  S/360  computers.  The  following  is  a list  of  operating  system  ser- 
vice capabilities  to  be  provided  for  both  releases  of  the  System: 

I 

1.  A computer-independent  interface  to  storage  management,  file  man- 

agement, program  management,  and  cost  assessment/diagnostic 
support  services  is  provided.  (This  permits  the  First  Level  release 
capability  to  be  available  on  CDC  6000/CYBER  computers  approxi- 
mately 4 months  after  its  availability  on  IBM  S/370  and  S/360  com- 
puters. ) , 

2.  Memory  utilization,  CPU  utilization,  and  file  utilization  statistics  are 
collected  throughout  the  run  and  converted  to  cost  estimates  at  analy- 
sis run  conclusion. 

3. 1. 2. 5 Support  Services 

A complete  set  of  services  is  provided  in  the  First  Level  Release  to  support 
methods  developers  in  the  development,  testing,  and  documentation  of  new  or 
modified  System  software.  In  addition,  services  are  also  provided  to  support  the 
management  of  the  System  software  and  data  configuration  and  to  support  the  in- 
stallation of  the  System  on  other  host  computers.  A separate  set  of  support  ser- 
vices is  provided  in  the  First  Level  Release  for  IBM  S/370  and  S/360  computers 
and  CDC  6000  and  CYBER  computers. 

3.2  SECOND  LEVEL  RELEASE 

* to 

As  indicated  in  Table  2,  the  analysis  capabilities  to  be  added  to  the  First  Level 
Release  capability  that  results  in  the  Second  Level  Release  capability  provide  a v 

complete  capability  to  accurately  predict  helicopter  performance,  stability  and 
control,  loads  and  vibrations,  acoustics,  and  aeroelastic  stability  for  a variety  of 
aircraft  configurations.  The  complete  capability  is  available  for  aircraft  config-  * 

u rations  during  three  life  cycle  analysis  phases:  preliminary  design,  detailed 
design,  and  research.  Major  new  executive/ support  capabilities  provided  in  the 
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Second  Level  Release  Include  a fully  interactive  user  environment  and  an  analysis 
run  cost  prediction  capability. 

3.2.1  Second  Level  Release  Analysis  Capabilities 

The  level  of  detail  at  which  individual  components  of  a physical  configuration  can 
be  represented  is  significantly  expanded  in  the  Second  Level  Release.  This  ex- 
pansion is  essential  if  the  System  is  to  be  useful  during  the  research  life  cycle 
phase  of  helicopter  analysis.  A significant  addition  to  the  First  Level  Release  is 
a capability  to  assess  the  effects  of  damage  to,  or  failure  of,  the  various  aircraft 
components  (rotor,  fuselage,  engine/drive  system,  controls,  etc.).  This  failure/ 
damage  assessment  capability  is  particularly  useful  during  the  detailed  design  and 
research  life  cycle  phases  of  helicopter  analysis. 

The  Second  Level  Release  also  includes  a significantly  expanded  acoustics  analy- 
sis capability.  Specific  capabilities  are  added  to  the  First  Level  Release  to  cal- 
culate rotor  external  noise,  engine  noise,  gearbox  noise,  and  noise  contributions 
from  aircraft  accessories. 

Finally,  an  automated  capability  is  planned  for  supporting  the  very  important  task 
of  assessing  the  accuracy  and  validity  of  the  System  analysis  capabilities.  This 
accuracy  assessment  capability  will  be  particularly  useful  during  the  System 
Validation  Phase. 

3. 2. 1. 1 Simulation  Model  Initialization 

The  Simulation  Model  Initialization  Subsystem  software  elements  included  in  the 
First  Level  Release  are  upgraded  to  reflect  model  initialization  requirements 
which  correspond  to  the  new  simulation  modeling  capabilities  included  in  the  Sec- 
ond Level  Release.  No  new  software  elements,  beyond  those  provided  in  the  First 
Level  Release,  are  planned  for  the  Second  Level  Release. 

3. 2. 1. 2 Simulation  Modeling 

Major  additions  to  the  First  Level  Release  simulation  modeling  capabilities  are 
planned  for  the  Second  Level  Release.  The  rotor  representations  are  expanded  to 
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include  semiempirical  circulation  control  rotors,  semiempirical  reaction  drive 
rotors,  pendulum  absorbers,  control  load  reduction  devices,  and  servo  flaps. 

The  control  system/pilot  representations  are  expanded  to  include  elastic  control 
systems,  dynamic  control  systems,  force  feel  systems,  automatic  flight  control 
systems,  control  feedback  from  force/motion  sensors,  and  pilot  transfer  func- 
tions. The  engine/drive  system  representations  are  expanded  to  include  a detailed 
engine  analysis  with  governor  and  fuel  control;  a rigid,  static  elastic,  and  dy- 
namic gearbox;  a dynamic  drive/shaft;  and  a clutch.  The  airframe  representa- 
tions are  expanded  to  include  a static  elastic  and  dynamic  fuselage,  a static  elastic 
and  dynamic  aerodynamic  surface,  vibration  control  devices,  suspended  cargo, 
complex  landing  gear,  dynamic  stores,  and  hoist  and  load  stabilization  devices. 
The  airmass  representations  are  expanded  to  include  free  rotor  wake,  cable  aero- 
dynamics, wind  tunnel- corrections,  and  aerodynamic  interference  effects  between 
and  among  rotors,  aerodynamic  surfaces,  and  bodies.  Also  included  is  an  ad- 
vanced unsteady  aerodynamic  analysis  capability  and  an  aerodynamic  solution  for 
arbitrary  bodies  and  nonrotating  lifting  surfaces.  Representations  of  other  analy- 
sis components  have  been  expanded  to  include  a dynamic  test  stand,  an  elastic  or 
plastic  deformable  ground  or  deck  surface,  and  a water  surface.  For  each  air- 
craft component  (i.e. , rotor,  control  system,  engine/drive  system,  and  air- 
frame), the  capability  to  simulate  component  failure  or  damage  is  also  added  in 
the  Second  Level  Release.  The  specific  simulation  modeling  capabilities  to  be 
added  to  the  First  Level  Release  are  presented  in  Sections  3. 2. 1. 2. 1 through 
3. 2. 1.2.7  in  terms  of  the  various  analysis  components. 

3. 2. 1.2.1  Rotor 

The  additional  rotor  simulation  modeling  capabilities  to  be  included  in  the  Second 
Level  Release  are  listed  below,  together  with  the  software  elements  which  provide 

the  capabilities. 
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Capability 


Software  Element 


Calculate  the  matrix  elements  and  forcing 
function  representing  steady-state,  oscil- 
latory, and  transient  rotor  response, 
including  elastic  bending  and  torsion  of 
the  hub  and  blade  components 

Compute  approximate  performance  of  a 
circulation  control  rotor  using  simple 
equations 

Compute  approximate  performance  of  a 
reaction  drive  rotor  using  simple  equa- 
tions 

Calculate  the  forcing  function  repre- 
senting the  shears  and  moments  input  to 
the  rotor  from  a reaction  drive 

Calculate  the  matrix  elements  repre- 
senting a blade-mounted  out-of-plane 
pendulum 

Calculate  the  matrix  elements  repre- 
senting a blade-mounted  in-plane 
pendulum 

Calculate  the  matrix  elements  repre- 
senting a rotor-mounted  control  load 
reduction  device,  and  the  forcing  function 
representing  the  loads  transmitted  to  the 
rotor 

Calculate  the  matrix  elements  repre- 
senting a rotor  servo-flap,  and  the 
forcing  function  representing  the  loads 
imparted  to  the  rotor  and  control  system 
by  the  flap 

3. 2. 1. 2. 2 Control  System/Pilot 


Elastic  Substructured  Rotor  Anal- 
ysis Subpackage 


Semi-Empirical  Circulation  Con- 
trol Rotor  Subpackage 

Semi-Empirical  Reaction  Drive 
Rotor  Subpackage 

Reactive  Drive  Rotor  Subpackage 


Rotor  Out-of-Plane  Pendulum  Sub- 
package 

Rotor  In-Plane  Pendulum  Subpack- 
age 

Rotor  Control  Load  Reduction 
Devices  Subpackage 


Rotor  Servo  Flaps  Subpackage 


The  additional  control  system/pilot  simulation  modeling  capabilities  to  be  included 
in  the  Second  Level  Release  are  listed  below,  together  with  the  software  elements 
which  provide  the  capabilities. 
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Calculate  the  stiffness  matrix  elements  Static  Elastic  Control  System  Sub- 

and  the  forcing  function  representing  a package 

flexible,  but  not  dynamic,  control  system 

Calculate  the  matrix  elements  and  Dynamic  Control  System  Subpack- 
forcing function  for  a dynamic  control  age  * 

system 

Compute  loads  and  vibrations  for  all  Control  System  Loads  and 

dynamic  components  of  the  control  sys-  Vibrations  Subpackage 

tern  from  the  response  calculated  for 
those  components 

Calculate  the  matrix  elements  and  con-  Automatic  Flight  Control  System 

trol  motion  forcing  functions  representing  Subpackage 
an  Automatic  Flight  Control  System 

Calculate  the  matrix  elements  and  con-  Control  Feedback  from  Force/ 

trol  motion  forcing  function  representing  Motion  Sensors  Subpackage 
control  feedback  from  force/motion  sen- 
sors 

Calculate  the  matrix  elements  and  control  Force  Feel  System  Subpackage 
motion  forcing  function  representing  an 
artificial  force  feel  system 

Calculate  the  matrix  elements  and  forcing  Pilot  Transfer  Function  Subpackage 
function  representing  pilot  response  to 
vibrations,  aircraft  motions,  and  aircraft 
accelerations 

Compute  control  positions  necessary  for  Simple  Circulation  Control  Rotor 

the  operation  of  a circulation  control  Control  System  Subpackage 

rotor 

i 

3 . 2 . 1. 2 . 3 E ngine/Drive  System 

The  additional  engine/drive  system  simulation  modeling  capabilities  to  be  included 

in  the  Second  Level  Release  are  listed  below,  together  with  the  software  elements 

which  provide  the  capabilities.  ' 
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Capability 

Generate  the  matrix  elements  and  forcing 
function  representing  an  engine  and  its 
transfer  functions  using  data  provided 
by  engine  manufacturers 

Calculate  the  matrix  elements  and  forcing 
function  representing  engine  performance 
characteristics  and  engine  dynamics 

Calculate  the  matrix  elements  repre- 
senting the  steady-state,  transient,  and 
dynamic  characteristics  of  all  engine 
management  components 

Calculate  the  matrix  elements  and  the 
forcing  functions  for  the  engine  and  for 
the  engine  management  components  re- 
lated to  a reaction  drive  mechanism 

Calculate  the  matrix  elements  and  the 
forcing  functions  for  the  engine  and  for 
the  engine  management  components  re- 
lated to  a circulation  control  drive  mech- 
anism 

Calculate  the  matrix  elements  and  forcing 
functions  for  the  engine  and  for  the  engine 
management  components  related  to  turbo- 
jet and  turbofan  engines 

Calculate  the  matrix  elements  and  the 
forcing  function  representing  a dynamic 
drive  shaft. 

Calculate  the  mass  matrix  elements  rep- 
resenting a rigid  gearbox 

Calculate  the  elements  of  a stiffness 
matrix  representing  a static  elastic  gear- 
box with  gear  train 

Calculate  the  matrix  elements  representing 
the  torsional  dynamic  characteristics  of 
a gearbox  with  gear  train 


Engine  Manufacturer  Simulation 
Subpackage 


Detail  Engine  Analysis  Subpackage 


Engine  Governor  and  Fuel  Control 
Subpackage 


Reaction  Drive  Subpackage 


Circulation  Control  Drive  Subpack- 
age 


Auxiliary  Propulsion  Subpackage 


Dynamic  Torsion  and  Bending 
Drive  Shaft  Subpackage 

Rigid  Gearbox  Subpackage 


Static  Elastic  Torsion  Gearbox 
Subpackage 


Dynamic  Torsion  Gearbox  Subpack- 
age 
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Capability 

Calculate  the  stiffness  matrix  elements 
representing  a flexible  nondynamic  drive 
belt 

Calculate  the  matrix  elements  repre- 
senting a clutch  component 

Calculate  the  loads  and  vibrations  for 
each  drive  system  component  based  upon 
the  response  of  each  drive  system  com- 
ponent 

Calculate  the  matrix  elements  repre- 
senting a dynamic  torsional  drive 
belt-pulley  system 

3. 2. 1.2. 4 Airframe 


Software  Element 


Static  Elastic  Drive  Belt  Subpack- 
age 

Clutch  Analysis  Subpackage 

Drive  System  Loads  and  Vibrations 
Subpackage 


Dynamic  Torsion  Drive  Belt  Sub- 
package 


The  additional  airframe  simulation  modeling  capabilities  to  be  included  in  the 
Second  Level  Release  are  listed  below,  with  the  software  elements  which  provide 
the  capabilities. 

Capability Software  Element 


Calculate  the  matrix  elements  and  forcing 
function  representing  a flexible  test  stand 
support  structure 

Calculate  both  the  matrix  elements  repre- 
senting a fuselage  or  a complete  airframe 
structure,  and  a forcing  function  repre- 
senting applied  external  forces 

Calculate  the  stiffness  matrix  elements 
and  the  forcing  function  representing  a 
static  elastic  pylon 

Calculate  the  matrix  elements  and  the 
forcing  function  representing  a dynamic 
pylon 

Calculate  the  stiffness  matrix  elements 
and  the  aerodynamic  forcing  function 
representing  static  elastic  aerodynamic 
surfaces 


Dynamic  Test  Stand  Subpackage 


Dynamic  Fuselage/Airframe 
Subpackage 


Static  Elastic  Pylon  Subpackage 


Dynamic  Pylon  Subpackage 


Static  Elastic  Aerodynamic  Sur- 
face Subpackage 
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Capability 


Software  Element 


Calculate  the  matrix  elements  and  the 
aerodynamic  forcing  function  repre- 
senting dynamic  aerodynamic  surfaces 

Calculate  the  matrix  elements  and  the 
forcing  function  representing  wheeled 
or  skid  landing  gear 

Calculate  the  mass  matrix  elements  and 
the  aerodynamic  forcing  function  repre- 
senting externally  suspended  rigid-body 
cargo 

Calculate  the  matrix  elements  and  the 
aerodynamic  forcing  function  repre- 
senting externally  suspended  flexible 
cargo 

Calculate  the  matrix  elements  and  the 
forcing  function  representing  a flexible 
cable 

Calculate  the  matrix  elements  and  the 
forcing  function  representing  either 
passive  or  active  vibration  control  de- 
vices 

Calculate  the  matrix  elements  and  the 
forcing  function  representing  cargo 
stabilization  devices  attached  to  the 
airframe 

Calculate  the  matrix  elements  and  the 
forcing  function  representing  a dynamic 
vibration  control  device  for  isolating 
cargo  loads  from  the  fuselage 

Calculate  airframe  loads  and  vibrations 
at  any  node  point  based  on  the  response 
of  each  airframe  component 

Calculate  the  matrix  elements  and  forcing 
function  representing  dynamic  fuselage- 
mounted  and  wing-mounted  stores 


Dynamic  Aerodynamic  Surface 
Subpackage 

Detailed  Landing  Gear  Subpackage 


Rigid  Suspended  Cargo  Subpackage 


Dynamic  Suspended  Cargo  Subpack 
age 


Cable  Subpackage 


Vibration  Control  Device  Subpack- 
agc 


Suspended  Cargo  Stabilization 
Devices  Subpackage 


Hoist  and  Load  Isolation  Subpack- 
age 


Airframe  Loads  and  Vibrations 
Subpackage 

Dynamic  Stores  Subpackage 
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Calculate  the  matrix  elements  and  forcing 
function  representing  the  effects  of  fuel 
and  fuel  slosh  on  fuselage  dynamics 

3.2.1. 2. 5 Airmass 


Fuel  Subpackage 


The  additional  airmass  simulation  modeling  capabilities  to  be  included  in  the 
Second  Level  Release  are  listed  below,  together  with  the  software  elements  which 


provide  the  capabilities. 

Capabili 


Compute  unsteady  aerodynamic  coeffi- 
cients using  state-of-the-art  stall  delay 
techniques 

Compute  the  matrix  elements  and  the 
forcing  function  representing  the  geome- 
try of,  and  the  induced  velocity  field  due 
to,  a free  wake 

Determine  the  induced  velocity  field  at 
all  lifting  surfaces  from  a table  of  induced 
velocities 

Compute  the  aerodynamic  coupling  effects 
between  two  rotor  systems 

Compute  the  aerodynamic  coupling  effects 
between  a rotor  and  an  aerodynamic  sur- 
face 

Compute  the  aerodynamic  coupling  effects 
between  a fuselage  and  an  aerodynamic 
surface 

Compute  the  aerodynamic  coupling  effects 
between  two  airframe  components 

Compute  the  aerodynamic  loads  on,  and 
velocities  due  to,  arbitrarily  shaped, 
nonrotating,  nonlifting  bodies  and  sur- 
faces 


•Software  Element 


Unsteady  Airloads  for  Time  Delay 
Subpackage 

Free  Wake  Subpackage 


Table  Look-Up  Flow  Field  Sub- 
package 

Rotor-to-Rotor  Interference  Sub- 
package 

Rotor-to-Aerodynamic  Surface 
Interference  Subpackage 

Fuselage-to-Aerodynamic  Surface 
Interference  Subpackage 

General-Purpose  Aerodynamic 
Interference  Subpackage 

Aerodynamic  Panel  Method  for 
Arbitrary  Bodies  Subpackage 


OHM***  i ?" 


Capability 


Software  Element 
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Compute  the  aerodynamic  loads  on,  and  Nonrotating  Aerodynamic  Surface 

velocities  due  to,  an  arbitrarily  shaped.  Potential  Flow  Subpackage 

nonrotating,  lifting  or  nonlifting  surface 

Compute  the  forces  and  moments  gen-  Semi-Empirical  Circulation  Con- 
erated by  a circulation  control  rotor  by  trol  Aerodynamics  Subpackage 

the  use  of  simple  equations  or  table  look- 
up 

Compute  the  aerodynamic  loads  on  a Cable  Aerodynamics  Subpackage 

cable  in  transverse  flow 

Compute  analytically  the  aerodynamic  Analytical  Wind  Tunnel  Boundary 

effects  of  wind  tunnel  boundaries  on  a Corrections  Subpackage 

body  in  the  tunnel 

Compute  from  empirical  data  the  aero-  Empirical  Wind  Tunnel  Boundary 

dynamic  effects  of  wind  tunnel  boundaries  Corrections  Subpackage 
on  a body  in  the  tunnel 

3.  2. 1. 2. 6 Ground/Deck  Surface 

The  additional  ground/deck  surface  modeling  capabilities  to  be  included  in  the 
Second  Level  Release  are  listed  below,  together  with  the  software  elements  which 
provide  the  capabilities. 

Software  Element 

Calculate  the  matrix  elements  and  the  Dynamic  Elastic  Ground/Deck 

contact  forcing  function  representing  an  Surface  Subpackage 

elastic  three-dimensional  ground/deck 
surface 

Calculate  the  matrix  elements  and  the  Elastic/Plastic  Ground/Deck 

contact  forcing  function  representing  an  Surface  Subpackage 

elastic/plastic  three-dimensional  ground/ 
deck  surface 

Calculate  the  matrix  elements  and  the  Water  Surface  Subpackage 

contact  forcing  function  representing  a 
simple  water  surface 
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No  additional  methods  for  coupling  components,  beyond  the  component  modes  , 

method  included  in  the  First  Level  Release,  are  planned  for  inclusion  in  the  Sec- 
ond Level  Release.  However,  if  Development  Phase  funding  permits,  it  is  rec- 
ommended that  the  substructure  analysis  method  for  coupling  components  be 
included  in  the  Second  Level  Release  (see  Section  2. 1 of  this  report  for  a more 
complete  discussion  of  this  recommendation). 

3. 2. 1.3  Trim  * 

A third  trim  solution  capability  is  added  to  the  two  capabilities  included  in  the 
First  Level  Release.  This  new  capability  finds  a steady-state  solution  by  dividing 
the  equations  of  motions  into  groups  and  iterating  for  a solution  on  each  group 
separately.  This  approach  eliminates  convergence  problems  experienced  when 
the  iteration  includes  all  the  equations  of  motion.  This  new  Second  Level  Release 

capability  is  provided  by  the  Decoupled  Iterate-To-Trim  Package. 

* 

3. 2. 1.4  Maneuvers 

i Two  new  maneuver-related  capabilities  are  added  to  the  maneuver  capabilities 

included  in  the  First  Level  Release.  The  first  new  capability  (provided  by  the 
Gust  Response  Package)  calculates  the  disturbance  in  the  fluid  flow  field  due  to 
user-specified  gusts,  trailing  vortices,  or  weapons  blasts.  The  second  new  capa- 
bility (provided  by  the  Initiate  Failure/Damage  Effects  Package)  activates  the 

f * » ' 1 

modeling  of  the  effects  of  component  failure  or  component  damage  as  and  when 
indicated  by  the  user.  Actual  component  failure  or  damage  is  simulated  by  the 

* 

simulation  modeling  capabilities  provided  for  each  aircraft  component  (Sec- 
tion 3. 2. 1. 2). 

\ 

3. 2. 1.5  Stability  and  Control  * 

The  complete  stability  and  control  analysis  capability  is  provided  in  the  First 
Level  Release. 
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3.2.1.  6 Acoustics 
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The  additional  acoustics  analysis  capabilities  to  be  included  in  the  Second  Level 

Release  are  listed  below,  together  with  the  software  elements  which  provide  the 

| 

r 

capabilities. 

ar 

Capability 

Software  Element 

Calculate  the  rotational  component  of 
rotor  external  noise  at  integer  harmonics 

Rotor  Rotational  Sound  Subpackage 

r 

Calculate  the  broadband  component  of 
rotor  external  noise  at  other  than  integer 
harmonics 

Rotor  Broadband  Sound  Subpack- 
age 

Calculate  the  reciprocating  engine  noise 
component  of  helicopter  far-field  and 
near-field  external  noise 

Reciprocating  Engine  Sound  Sub- 
package 

Calculate  the  turbine  engine  noise  com- 
ponent of  helicopter  far-field  and  near- 
field external  noise 

Turbine  Engine  Sound  Subpackage 

Calculate  the  external  and  internal  noise 
contributions  from  the  main  transmission 
or  any  gearbox,  taking  into  account  the 
type  of  gearing,  case  sound  transmissi- 
bility,  isolation,  and  installation  effects 

Gearbox  Sound  Package 

Calculate  the  external  and  internal  noise 
contributions  from  accessories  such  as 
oil  cooler  fans,  hydraulic  pumps,  bypass 
valves,  ECUs,  APUs,  ventilation  fans, 
generators/altemators,  and  avionics 

Accessories  Sound  Package 

' 

r 
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equipment 

3.2. 1.7  Aeroelastic  Stability 

The  three  alternative  aeroelastic  stability  analysis  capabilities  included  in  the 
First  Level  Release  provide  all  the  required  aeroelastic  stability  analysis  capa- 
bilities. 


3. 2. 1. 8 General  Mathematical  Operations 

The  general  mathematical  operation  capabilities  included  in  the  First  Level  Re- 
lease provide  all  the  required  general  mathematical  operation  capabilities. 

3. 2. 1. 9 External  Models  Interface 


No  interface  capability  to  other  external  models  (beyond  the  one  external  model 
interface  capability  included  in  the  First  Level  Release)  is  planned  for  the  Second 
Level  Release  because  no  external  models  are  currently  specified. 


3. 2. 1. 10  Accuracy  Assessment 

The  Second  Level  Release  provides  automated  support  for  assessing  the  accuracy 
of  an  analysis.  This  automated  capability  is  intended  to  support  the  System  Vali- 
dation Phase.  The  detailed  accuracy  assessment  capabilities  planned  for  inclu- 
sion in  the  Second  Level  Release  are  listed  below,  together  with  the  software 


elements  which  provide  the  capabilities. 

Capability 

Define  a series  of  cases  to  be  run  with 
perturbations  to  user-specified  input 
evaluation  variables 

Calculate  the  partial  derivatives  of  each 
of  the  user-specified  output  evaluation 
variables  with  respect  to  each  of  the 
specified  input  evaluation  variables 

Find  standard  deviations  for  the  output 
variables  as  a basis  for  the  expected 
values  and  reasonable  ranges  of  experi- 
mental data 

Compare  computed  results  with  experi- 
mental results  to  support  the  evaluation 
of  the  validity  and  accuracy  of  System 
results 


Software  Element 


Set  Up  Accuracy  Assessment 
Cases  Packages 

Compute  Sensitivity  Factors  Pack- 
age 


Generate  Expected  Values  and 
Ranges  Package 


Compare  Computed  Values  Versus 
Experimental  Data  Package 


f 
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3.  2. 2 Second  Level  Release  Executive/Support  Capabilities 

The  major  Second  Level  Release  enhancements  to  the  First  Level  Release 
executive/support  capabilities  are  in  two  categories:  user  interface  and  operating 
system  services.  The  detailed  executive/support  capabilities  added  to  the  First 
Level  Release  in  the  Second  Level  Release  are  presented  in  terms  of  the  same  five 
capability  categories  used  in  Section  3.1.2  to  present  the  First  Level  Release 
executive/support  capabilities. 

3.2. 2.1  User  Interface 

The  major  Second  Level  Release  enhancements  to  the  First  Level  Release  user 
interface  capabilities  are  in  two  areas:  complete  user  interactivity  and  prediction 
of  analysis  run  costs.  Specific  capability  enhancements  to  the  user  interface  capa- 
bilities provided  in  the  First  Level  Release  are  as  follows : 

1.  A tutorial  capability  is  available  to  users  at  interactive  terminals. 

(This  tutorial  capability  will  help  the  user  define  component  model 
data  and  compose  System  commands. ) 

2.  The  user  may  suspend  processing  after  any  desired  System  Command 
in  order  to  inspect  analysis  results  thus  far  computed,  to  modify  the 
sequence  of  System  Commands,  or  to  do  both. 

3.  A prediction  of  the  costs  of  an  analysis  will  be  provided  before  the 
analysis  is  performed.  (If  the  predicted  costs  indicate  delayed  access 

to  the  computer  because  of  Installation  restrictions,  the  user  can  then  , 

reduce  the  complexity  of  the  analysis,  and  the  resulting  analysis  costs, 
to  gain  quicker  access  to  the  computer. ) 

4.  The  user  can  define,  at  an  interactive  terminal,  the  formats  to  be 
used  for  each  printed  report  or  plot.  (The  First  Level  Release 
provides  a similar  capability;  however,  the  First  Level  Release  capa- 
bility is  restricted  to  a predefined  set  of  optional  formats.  With  the 
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Second  Level  Release,  the  user  can  explicitly  define  the  formats  best 
suited  to  the  user  and  to  the  problem  being  analyzed. ) 

5.  A Master  Command  File  containing  an  expanded  set  of  validated  Sys- 
tem Command  Sequences  needed  to  use  the  particular  functional  capa- 
bilities of  the  Second  Level  Release  is  provided  to  all  users  of  the 
Second  Level  Release. 

3. 2 . 2 . 2 Run-Time  Management 

Run-time  management  capabilities  are  complete  for  the  First  Level  Release  and 
therefore  no  additional  capabilities  are  planned  for  the  Second  Level  Release. 

3. 2.  2. 3 Data  Base  Management 

Data  base  management  capabilities  are  complete  for  the  First  Level  Release  and 
therefore  no  additional  capabilities  are  planned  for  the  Second  Level  Release. 

3.  2.  2. 4 Operating  System  Services 

For  the  Second  Level  Release,  all  First  Level  Release  operating  system  service 
capabilities  are  available  on  both  IBM  S/370  and  S/360  computers  and  CDC  6000 
and  CYBER  computers.  One  additional  operating  system  service  capability  is 
included  in  the  Second  Level  Release:  a computer  and  device-independent  inter- 
face to  interactive  terminals  is  provided. 

3. 2. 2. 5 Support  Services 

Support  service  capabilities  are  complete  for  the  First  Level  Release  and  there- 
fore no  additional  capabilities  are  planned  for  the  Second  Level  Release. 


SECTION  4 - SYSTEM  USE 


The  various  uses  of  the  System  are  divided  into  four  categories: 

• The  use  of  the  System  to  perform  standard  analyses 

• The  use  of  the  System  to  develop  new  analysis  capabilities 

• Interactive  use  of  the  System 

• Supporting  use  of  the  System 

Section  4.1  summarizes  these  four  uses.  The  succeeding  sections  contain  more 
detailed  information  about  topics  referred  to  in  Section  4.1. 

4. 1 SYSTEM  USE  OVERVIEW 

To  perform  a standard  engineering  analysis,  the  System  user  submits  a deck  of 
cards  (or  a file  of  card  images)  containing  information  in  the  form  described  in 
Section  4.3,  User  Input.  The  user  input  is  designed  to  allow  the  user  to  express 
the  analysis  to  be  performed  in  terms  that  are  descriptive  of  the  problem  to  be 
solved  rather  than  in  terms  of  the  steps  the  System  should  take  to  solve  the  prob- 
lem. Knowledge  of  the  physical  configuration  to  be  analyzed  is  emphasized  rather 
than  knowledge  of  the  System  that  will  perform  the  analysis.  The  user  input  is  also 
designed  to  be  self-documenting.  Most  of  the  statements  that  appear  in  the  user 
input  are  English-language  statements  that  will  be  clear  to  the  user  with  minimal 
explanation.  In  addition,  the  user  may  supply  comment  cards  to  further  document 
the  input. 

Most  of  the  information  required  to  describe  the  physical  configuration  to  be  ana- 
lyzed, the  conditions  for  the  analysis,  and  the  failure  or  damage  effects  to  be  con- 
sidered is  normally  contained  in  the  Master  Data  Base,  described 'in  Section  4.2. 

If  the  information  is  contained  in  the  Master  Data  Base,  the  user  simply  names  the 
sets  in  the  Master  Data  Base  that  contain  the  information.  Changes  to  the  data 
contained  in  the  Master  Data  Base  for  this  run  only  may  be  specified  in  user  input. 

If  the  information  required  to  describe  the  analysis  to  be  performed  is  not  contained 
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in  the  Master  Data  Base,  the  entire  description  may  be  contained  in  user  input. 

The  maintenance  and  dissemination  of  the  contents  of  the  Master  Data  Base  are  the 
responsibility  of  each  individual  installation  and  will  undoubtedly  be  performed  in 
j many  different  ways.  Typically,  a catalog  of  the  current  sets  in  the  Master  Data 

Base  will  be  maintained  either  by  distribution  to  the  System  users  or  in  a file  ac- 
cessible to  System  users.  To  make  the  most  efficient  use  of  the  System,  a user  . 

must  know  what  data  are  available  in  the  Master  Data  Base. 

The  System  action  upon  receipt  of  user  input  is  to  create  a Run  Data  Base,  de- 
scribed in  Section  4.6,  and  a Sequence  Control  Table.  The  Run  Data  Base  contains 
input  data  from  the  Master  Data  Base  as  modified  by  user  input  and,  as  the  run 
proceeds,  it  will  contain  intermediate  and  final  results.  The  Sequence  Control 
| Table  contains  System  Commands,  described  in  Section  4. 5,  selected  from  the 

Master  Command  File  based  on  information  implicit  in  user  input. 

To  use  the  System  for  developing  new  analysis  capabilities,  a more  detailed  knowl- 
edge of  the  System  is  required  than  for  performing  standard  analyses  as  described 
above.  The  methods  developer  will  normally  be  adding  new  software  elements  to 
the  System  and  will  be  testing  their  effectiveness  in  performing  helicopter  analyses. 

To  perform  a test,  the  methods  developer  must  use  the  Support  Complex  to  produce 

one  or  more  load-modules  containing  the  software  elements  to  be  added.  If  new  , 

data  elements  are  required  in  the  Master  Data  Base  or  the  Run  Data  Base,  they 
must  be  defined  by  use  of  the  Support  Complex.  The  methods  developer  must  then 
create  a sequence  of  System  Commands  that  will  cause  the  new  software  elements 
to  be  executed  in  their  proper  context.  The  form  of  user  input  as  described  in  Sec- 
tion 4. 3 will  be  extended  by  the  addition  of  a seventh  section,  which  will  contain  * 

explicit  definition  of  System  Command  Sequences  either  by  modification  of  existing 
sequences  in  the  Master  Command  File  or  by  creation  of  completely  new  sequences. 

By  use  of  user  input  containing  information  in  the  seventh  section,  the  user  de- 
‘ veloplng  new  capability  may  create  any  sequence  of  System  Commands  required. 
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The  System  can  be  used  interactively  to  perform  any  of  the  functions  described 
above,  because  the  host  operating  systems  for  both  the  Host  1 and  the  Host  2 fam- 
ilies of  computers  contain  the  capability  to  interactively  create  files,  submit  Jobs, 
and  examine  files.  This  capability  can  be  used  to  create  a file  containing  user  in- 
put, to  submit  a Job  to  perform  the  analysis  specified  in  the  user  input  file,  and  to 
examine  files  containing  the  results  of  the  analysis.  The  interactive  capabilities 
of  the  System,  in  addition  to  those  supplied  by  the  host  operating  systems,  are  as 
follows: 

1.  Print  or  plot  information  using  the  System's  formatting  capability  to 
produce  reports  specifically  designed  for  the  engineering  user  of  the 
System.  This  capability  may  be  used  to  examine  input  data,  inter- 
mediate results,  or  final  results. 

2.  Either  modify  an  existing  sequence  of  System  Commands  or  create  a 
new  sequence  of  System  Commands,  and  then  execute  the  sequence  of 
System  Commands.  This  capability  may  be  used  to  test  partial  se- 
quences of  System  Commands.  When  System  Commands  are  executed 
from  an  interactive  terminal,  the  execution  of  a STOP  command  causes 
control  to  return  to  the  user  at  the  terminal.  The  terminal  user  may 
then  examine  intermediate  results,  continue  execution  at  the  command 
immediately  following  the  STOP  command,  further  modify  the  sequence 
of  System  Commands,  continue  execution  from  any  other  point  in  the 
sequence,  or  perform  any  other  function  normally  available  from  an 
interactive  terminal.  Specifically,  to  monitor  the  result  of  executing 
each  System  Command  in  a sequence,  the  terminal  user  would  insert  a 
STOP  command  after  each  System  Command  in  the  sequence  and  exe- 
cute the  sequence.  The  terminal  user  then  regains  control  at  the  ter- 
minal after  each  System  Command  is  executed  and  may  examine  the 
results. 
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3.  Provide  tutorial  information.  Tutorial  information  includes  general 

information  about  the  System  and  its  use,  information  about  the  current 
contents  of  the  Master  Data  Base  or  the  Run  Data  Base,  and  information 
about  sequences  of  System  Commands.  Tutorial  information  is  de- 
signed to  be  used  by  the  engineering  user  to  prepare  input  for  an  analy- 
sis run  or  by  the  methods  developer  to  prepare  runs  for  testing  new  or 
improved  analysis  methods. 

The  System  may  be  used  to  support  its  engineering  analysis  use  and  methods  de- 
velopment use  in  several  ways.  The  most  frequent  supporting  use  of  the  System 
will  be  for  maintenance  of  the  Master  Data  Base.  The  Master  Data  Base  may  be 
created  or  changed  only  by  an  authorized  person  at  an  Installation  through  use  of 
the  Data  Base  Support  Package  of  the  Support  Complex.  The  conventions  for  set 
names,  criteria  for  inclusion  of  data,  authorization  of  update  capability,  and  other 
policy  matters  regarding  the  maintenance  of  the  Master  Data  Base  will  be  de- 
cided individually  at  each  installation.  The  goals  of  the  Master  Data  Base  main- 
tenance policy  should  be  to 

1.  Maintain  a stable,  verified  source  of  data 

2.  Quickly  add  data  likely  to  be  used  repeatedly 

3.  Rapidly  disseminate  knowledge  of  Master  Data  Base  contents  to  all  Sys- 
tem users 

The  capabilities  of  the  System  can  be  used  to  accomplish  the  first  two  of  these 
goals.  Test  versions  of  the  Master  Data  Base  may  exist  simultaneously  with  the 
primary  Master  Data  Base.  This  capability  allows  the  verification  of  data  prior  to 
inclusion  in  the  primary  Master  Data  Base  and  allows  the  test  of  new  software  ele- 
ments requiring  new  data  elements. 

The  System  will  assist  in  making  efficient  use  of  the  System;  i.  e. , the  System  has 
a cost  assessment  capability  that  can  be  used  to  estimate  the  cost  of  an  analysis 
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run  without  actually  making  the  run.  By  means  of  this  capability,  the  System  user 
can  decide  whether  the  results  to  be  derived  from  an  analysis  run  are  worth  the 
cost  of  the  run  or  can  choose  the  least  costly  of  several  alternative  ways  to  achieve 
the  desired  results. 

If  a directly  created  System  Command  Sequence  is  used  repeatedly  at  an  installa- 
tion, it  can  be  made  more  easily  available  to  System  users  by  the  use  of  another 
supporting  capability.  The  new  System  Command  Sequence  may  be  added  to  the 
Master  Command  File  by  use  of  the  Data  Base  Support  Package  of  the  Support 
Complex. 

In  summary,  the  System  may  be  used  in  a number  of  different  ways  and  for  a num- 
ber of  different  purposes.  The  primary  purpose  of  the  System,  to  perform  heli- 
copter analyses,  may  be  accomplished  in  a manner  ranging  from  a simple 
description  of  the  physical  configuration  to  be  analyzed  to  a complete  description 
of  the  steps  to  be  followed  by  the  System  in  performing  the  analysis.  Either  batch 
or  interactive  capability  may  be  used  in  accomplishing  these  analyses.  The  Sys- 
tem may  be  used  in  various  ways  to  support  its  primary  purpose.  Supporting 
uses  of  the  System  include  maintenance  of  the  Master  Data  Base,  assessment  of 
the  cost  of  an  analysis  run,  and  maintenance  of  the  Master  Command  File. 

4.2  MASTER  DATA  BASE 

The  Master  Data  Base  contains  descriptions  of  aircraft  components  and  other 
analysis  components  to  be  analyzed;  descriptions  of  coupling  between  and  among 
components;  descriptions  of  maneuvers,  conditions,  and  operating  regimes  for 
the  analysis;  and  descriptions  of  failure/damage  effects.  Information  Is  created 
or  changed  in  the  Master  Data  Base  only  by  an  authorized  person  through  use 
of  the  Data  Base  Support  Package  of  the  Support  Complex.  Information  is  read 
from  the  Master  Data  Base  during  the  input  phase  of  an  analysis  run  to  create 
the  Run  Data  Base.  The  System  user  specifies  in  user  input  the  data  in  the 
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Master  Data  Base  that  are  to  be  used  in  the  analysis  run.  The  System  user  also 
has  the  capability  to  change  the  data  read  from  the  Master  Data  Base  for  the  du- 
ration of  the  analysis  run.  The  Run  Data  Base  created  for  an  analysis  run  con- 
tains the  data  selected  from  the  Master  Data  Base  by  statements  in  user  input. 

Section  4.3  describes  the  user  input  statements  that  cause  selection  and  modifica-  < 

tion  of  data  from  the  Master  Data  Base. 

The  data  in  the  Master  Data  Base  are  organized  into  a hierarchy  of  sets  of  data. 

A set  is  a collection  of  data  that  is  identified  and  managed  as  a single  entity  for 
convenience  and  efficiency.  A set  may  contain  any  combination  of  three  kinds 
of  elements:  other  sets,  arrays  of  data-items,  and  individual  data-items.  A 
set  contained  within  a set  has  characteristics  identical  to  the  containing  set. 

(To  avoid  the  awkward  nomenclature  of  "contained  set"  and  "containing  set"  in 
the  text  that  follows,  a set  contained  in  another  set  is  referred  to  as  a "subset. " 

This  does  not  identify  a new  type  of  element  in  the  Master  Data  Base. ) An  array 
of  data-items  is  a collection  of  data-items  that  are  identified  by  an  array  name  and 
an  index  in  the  array  rather  than  by  Individual  names.  The  indexes  may  be  multi- 
dimensional. A data-item  is  the  smallest  identifiable  element  in  the  Master  Data 
Base.  Data-items  that  are  not  members  of  arrays  are  Identified  by  names. 

y 

Each  set,  array,  or  data-item  in  the  Master  Data  Base  has  a name.  Sets  in  the 
Master  Data  Base  are  named  at  the  time  the  sets  are  created.  The  conventions 

that  are  used  in  naming  sets  are  controlled  at  each  Installation  and  may  be  as  rigid  V 

or  as  flexible  as  the  installation  chooses.  Sets  will  usually  be  named  in  a way  to 

remind  the  user  of  the  object  or  condition  described  by  the  set.  For  example,  a * 

set  containing  the  description  of  a main  rotor  for  an  aircraft  with  model  number 

UH60A  might  be  named  UH60AMR  or  a set  describing  a slnewave  gust  response 

maneuver  might  be  named  GUSTSIN20.  The  hierarchical  structure  of  the  Master  * 

Data  Base  is  useful  for  representing  a physical  configuration  that  consists  of  com- 
ponents with  subcomponents  with  sub-subcomponents  to  as  fine  a level  of  detail  as 
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is  necessary  for  a complete  representation  of  an  aircraft  or  other  physical  config- 
uration. Using  this  strategy,  an  aircraft  can  be  represented  as  a single  set  i 

named,  for  example,  UH60A.  This  set  contains  sets  that  describe  components  of 
the  aircraft.  For  example,  some  of  the  subsets  might  be  UH60AMR,  mentioned 
above;  UH60ACT,  describing  the  control  system;  and  UH60AAF,  describing  the 
airframe. 

The  arrays  and  individual  data-items  in  the  Master  Data  Base  contain  the  values 
that  represent  the  physical  characteristics  of  the  physical  configuration  or  other 
entity  being  described.  These  values  must  be  supplied  to  the  software  elements 
of  the  Technology  Component  in  order  for  them  to  perform  the  required  analysis. 

The  array  names  and  data-item  names  are  the  primary  means  of  specifying  the 
values  that  are  to  be  made  available  to  each  individual  software  element.  For 
this  reason  the  names  of  arrays  and  data-items  may  not  be  arbitrarily  assigned 
when  a set  is  created.  Every  set  describing  a rotor,  regardless  of  the  name 
assigned  to  the  rotor  and,  hence,  to  the  set,  must  have  arrays  or  data-items 
with  specific  names  in  order  for  the  rotor  to  be  simulated  and  analyzed  by  the 
System.  Generally,  the  names  will  be  in  accord  with  the  document,  Nomen- 

36 

clature  for  the  Second-Generation  Comprehensive  Helicopter  Analysis  System. 

► 

Because  the  Data  Base  Management  Subsystem  is  used  to  retrieve  data  from 
the  Master  Data  Base,  it  is  possible  to  rearrange  the  arrays  and  data-items 

within  a set  and  even  to  add  new  arrays  or  data-items  without  disturbing  the  e 

software  elements  performing  the  analysis.  The  necessary  link  between  the  > 

System  and  the  data  is  the  name  of  the  array  or  the  data-item. 

Just  as  each  data  element  (set,  array,  or  data-item)  of  the  Master  Data  Base 
has  a name,  each  data  element  also  has  a type.  The  type  of  a data  element  is 



^NOMENCLATURE  OF  THE  SECOND-GENERATION  COMPREHENSIVE  HELI- 
COPTER ANALYSIS  SYSTEM,  Applied  Technology  Laboratory,  U.  S.  Army  Re- 
search and  Technology  Laboratories,  Fort  Eustls,  Virginia,  to  be  published. 
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assigned  when  the  element  is  created.  The  type  of  a set  is  similar  in  meaning  to 
the  type  of  the  entity  described  by  the  set.  For  example,  an  aircraft  of  type 
SRH  (single-rotor  helicopter)  has  certain  components,  including  an  engine  and 
a control  system.  A set  of  type  SRH,  describing  an  aircraft  of  type  SRH,  has 
sets  corresponding  to  the  aircraft  components,  including  a set  of  type  ENGINE 

a 

and  a set  of  type  CONTROL.  The  subdivision  of  types  can  be  carried  to  the 
level  of  detail  necessary  for  a complete  description  of  the  aircraft. 

Within  the  Master  Data  Base,  the  type  of  a set  specifies  an  entry  in  the  dic- 
tionary that  describes  the  characteristics  of  all  sets  of  that  type  which  are  in 
the  Master  Data  Base.  Among  the  characteristics  in  the  dictionary  are  the 
number  and  the  type  of  all  subsets  and  the  number  and  the  type  of  arrays  and 
data-items  in  the  set.  Each  name  of  a data  element  is  also  in  the  dictionary, 
along  with  the  type  of  the  named  data  element.  It  is  through  the  use  of  the  dic- 
tionary that  the  Data  Base  Management  Subsystem  retrieves  the  required  sets, 
arrays,  or  data-items  from  the  Master  Data  Base. 

An  example  of  some  sets  in  a Master  Data  Base,  along  with  their  associated 
names  and  types,  is  given  in  Figure  35.  In  this  example,  six  sets  are  defined 
at  the  highest  level  of  the  hierarchy.  Four  of  the  six  sets  describe  aircraft  of 
types  SRH  (single-rotor  helicopter),  TRH  (tandem-rotor  helicopter),  and  CRH 
(coaxial -rotor  helicopter).  The  other  two  sets  at  the  highest  level  of  the  hier- 
archy describe  components  of  type  ROTOR  and  AEROSURF  (aerodynamic  sur- 
face). The  DMG  at  the  end  of  the  names  of  these  last  two  sets  is  a reminder  1 

that  the  sets  describe  a damaged  main  rotor  and  aerodynamic  surface,  respec-  . 

tively,  for  helicopter  model  UH60A.  Some  of  the  subsets  of  set  UH60A  are  shown 
in  this  example.  Note  that  there  are  two  sets  of  type  ROTOR  and  that  to  distin- 
guish between  them  the  type  has  been  qualified  as  ROTOR  (MAIN)  or  ROTOR  * 

(TAIL).  Set  UH60AAF,  which  describes  the  airframe,  is  divided  into  subsets 
that  represent  components  of  the  airframe.  Those  shown  in  the  example  rep- 
resent components  FUSE  (fuselage),  AEROSURF  (aerodynamic  surface),  and 
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Figure  35.  Example  of  Sets  in  the  Master  Data  Base 
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LANDINGGEAR  (landing  gear).  There  are  two  sets  of  type  AEROSURF  that  are 
distinguished  by  qualifier.  In  this  example  the  set  names  are  indicative  of  the  data 
contained  in  the  sets.  The  extent  to  which  this  practice  is  followed  at  an  installa- 
tion is  completely  under  installation  control. 

4.3  USER  INPUT 

The  user  input  provides  a way  for  the  user  of  the  System  to  specify  the  kind  of 
analysis  the  System  is  to  perform;  the  physical  configuration  to  be  analyzed;  the 
maneuvers,  conditions,  and  operating  regimes  with  which  the  analysis  is  to  be 
performed;  any  failure/damage  effects  that  are  to  be  considered  in  the  analysis; 
and  any  System  options  such  as  alternative  analysis  techniques  or  output  other 
than  defaults.  The  user  input  data  is  normally  supplied  as  a card  deck  but  may 
also  be  a file  on  disk  or  tape.  In  most  cases  the  information  required  by  the  Sys- 
tem for  an  analysis  run  will  be  in  the  Master  Data  Base,  and  it  is  only  necessary 
for  the  user  input  to  name  the  sets  in  the  Master  Data  Base  that  contain  the  re- 
quired information  and  to  specify  the  changes  in  the  data  for  the  case.  If  the  in- 
formation is  not  contained  in  the  Master  Data  Base,  it  can  be  completely  supplied 
in  the  user  input. 

The  user  input  data  for  an  analysis  run  may  specify  more  than  one  case  as  part 
of  the  analysis  run.  The  user  input  has  the  same  form  for  each  case,  although 
different  data  may  be  used  or  different  options  may  be  exercised  in  the  different 


cases  of  the  analysis  run.  The  remainder  of  this  section  describes  the  form 

and  meaning  of  the  user  input  for  one  case  of  an  analysis  run. 

The  user  input  data  for  a case  is  divided  into  six  sections: 

t 

V 

1. 

Case  Specification  Section 

2. 

Configuration  Specification  Section 

3. 

Conditions  Specification  Section 

4. 

Failure/Damage  Specification  Section 
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5.  Options  Specification  Section 

6.  Accuracy  Assessment  Specification  Section 
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The  Case  Specification  Section  must  be  present  in  the  user  input  for  each  case,  ; 

and  the  Configuration  Specification  Section  and  Conditions  Specification  Section  1 

must  be  present  in  the  first  case  of  an  analysis  run.  All  other  sections  of  user 

I 

input  are  optional;  each  section  is  present  only  if  information  in  that  section 
is  required  for  the  analysis  to  be  performed. 

Each  section  of  user  input  begins  with  a word  indicative  of  the  name  of  the  sec- 
tion followed  by  a colon.  The  introductory  words  are 

\ 

1.  CASE: 

2.  CONFIGURATION: 

3.  CONDITIONS:  I 

4.  FAILUREDAMAGE: 

* 

5.  OPTIONS: 

6.  ACCURACY:  ' 

Each  of  the  six  keywords  that  introduce  a section  must  be  the  first  word  on  the 

card  or  card  image  that  is  the  first  card  of  the  section.  With  that  exception, 
the  user  input  data  is  free-form;  that  is,  it  can  begin  in  any  column,  and  mul- 
tiple  statements  may  appear  on  a card.  This  enables  the  System  user  to  ar- 
range the  user  input  in  an  easily  readable  format.  The  six  sections  of  user 
input  data  are  specified  in  Sections  4. 3. 1 through  4. 3.6. 

V 1 

4.3.1  Case  Specification  Section 

The  Case  Specification  Section  identifies  the  analysis  run  and  the  case  and  speci- 
fies the  type  of  analysis  to  be  performed  for  this  case.  The  Case  Specification 
Section  has  four  kinds  of  statements.  The  first  three  statements  are  as  follows: 

CASE: 

ANALYSIS  RUN  ID  Identification  of  analysis  run. 

CASE  ID  identification  of  this  case. 
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The  next  statement  specifies  three  items:  aircraft  life  cycle  phase  and  aircraft 
technical  characteristic,  cost  assessment  (if  desired),  and  units  to  be  used  for 
input  data. 

An  example  of  a full  Case  Specification  Section  is  as  follows: 

CASE: 

• 

ANALYSIS  RUN  ID  PERFORMANCE  OF  UH60A. 

CASE  ID  ROTOR  ZZ435- 

DETAILED  DESIGN  PERFORMANCE,  ASSESS  COST,  METRIC 
UNITS 

The  statements  shown  here  are  written  on  separate  lines  and  indented.  This 
form  of  preparation  of  the  user  input  data  is  recommended  for  readability  and 
ease  of  change,  but  it  is  not  required  by  the  System. 

Under  certain  conditions,  some  of  the  statements  of  the  Case  Specification  Sec- 
tion may  be  omitted.  The  first  case  of  an  analysis  run  must  identify  the  run, 
but  the  ANALYSIS  RUN  ID  statement  may  be  omitted  from  all  cases  after  the 
first.  If  there  is  only  one  case,  the  CASE  ID  statement  may  be  omitted.  The 
phrase  ASSESS  COST  is  included  only  if  a cost  estimate  is  desired  for  this 
case.  The  last  phrase  in  the  last  statement  may  be  either  ENGLISH  UNITS  or 

I 

METRIC  UNITS.  If  English  units  are  to  be  used,  the  phrase  may  be  omitted. 

The  example  given  above  identifies  the  analysis  run  as  PERFORMANCE  OF 
UH60A.  The  identification  of  the  analysis  run  is  printed  as  a primary  heading 

t 

on  each  page  of  printed  or  plotted  output  from  the  run.  The  case  above  is  iden- 
tified as  ROTOR  ZZ435.  The  case  identification  is  printed  as  a secondary 
heading  on  each  page  of  printed  or  plotted  output  from  the  run.  Presumably 
other  cases  in  this  analysis  run  will  analyze  the  performance  of  UH60A  with 
other  rotors.  The  last  line  of  the  example  shown  above  specifies  that  the  Sys- 
tem is  to  make  a PERFORMANCE  analysis  for  the  DETAILED  DESIGN  life 
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PRELIMINARY  DESIGN  life  cycle  phase.  Values  in  user  input  data  are  in 
ME  TRIG  UNITS. 

Example  3: 

CASE:  ANALYSIS  RUN  ID  PROJECT  ANALYZE— DA Y43—RUN14. 

CASE  ID  AEROELELASTIC  STABILITY.  RESEARCH  AEROELASTIC 
STABILITY 

In  this  example  the  user  has  chosen  to  run  all  his  statements  together  for  his 
own  reasons.  This  Case  Specification  Section  causes  the  System  to  perform 
an  AEROELASTIC  STABILITY  analysis  for  the  RESEARCH  life  cycle  phase. 

The  values  in  user  input  data  are  in  English  units. 

4. 3. 2 Configuration  Specification  Section 

The  Configuration  Specification  Section  describes  the  configuration  to  be  ana- 
lyzed. This  section  includes  data  for  aircraft  components,  other  analysis  com- 
ponents, and  coupling  of  components.  The  configuration  to  be  analyzed  may  be 
a complete  aircraft  or  a part  of  an  aircraft.  Examples  of  the  latter  are  a rotor 
(possibly  with  major  drive  system  components)  mounted  on  a whirl  stand,  and 
a combination  of  components  in  a wind  tunnel. 

The  introductory  statement  to  the  Configuration  Specification  Section  must  be 
the  first  word  on  a card  and  is  as  follows: 

CONFIGURATION: 

If  the  data  describing  the  configuration  to  be  analyzed  are  in  the  Master  Data 

Base,  the  next  statement  in  the  Configuration  Specification  Section  is  a set 

specification  statement  that  gives  the  type  of  configuration  to  be  analyzed  and 

the  name  of  the  set  from  the  Master  Data  Base  that  contains  the  data  for  that 

configuration.  The  form  of  the  set  specification  statement  is  as  follows:  • 

type  = set  name 
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The  set  specification  statement  may  be  on  the  same  card  as  CONFIGURATION: 
or  on  a succeeding  card;  for  example, 

CONFIGURATION:  SRH  = UH60A 

means  that  the  type  of  physical  configuration  to  be  i nalyzed  is  a single  rotor  heli- 
, copter  and  that  the  set  with  name  UH60A  contains  the  data  describing  the  configura- 

tion. The  System  will  verify  that  set  UH60A  is  of  type  SRH.  If  the  System  finds 
a type  mismatch,  it  produces  a diagnostic  message  informing  the  user  of  the  dis- 

* crepancy.  For  a discussion  of  set  types,  see  Section  4.2.  For  another  example, 

CONFIGURATION: 

MRWR  = RWS53 

means  that  the  configuration  to  be  analyzed  is  of  type  MRWR  (main  rotor  on  a 
whirl  rig)  and  that  the  set  with  the  name  RWS53  describes  the  configuration. 

The  type  of  the  configuration  named  in  the  set  specification  statement  must  be 
one  of  a list  of  types  of  configuration  that  the  System  can  analyze.  The  types 
of  configuration  that  the  System  can  analyze  and,  hence,  the  types  of  sets  that 
can  be  named  in  the  set  specification  statement  are  equivalent  to  the  Detailed 
Functional  Capability  Physical  Systems  defined  in  the  Government  Draft  on 
Detailed  Functional  Capabilities  (i.  e. , tables  from  Section  30  of  the  Type  A 
System  Specification).  For  example,  sets  describing  an  aircraft-only  physical 
system  are  of  types  SRH  (single-rotor  helicopter),  TRH  (tandem-rotor  helicopter), 
CRH  (coaxial-rotor  helicopter),  etc.  Sets  describing  a main  rotor  on  a whirl  rig 
are  of  type  MRWR. 

P 

Once  a set  with  a valid  type  is  named  in  the  set  specification  statement  of  the 
Configuration  Specification  Section,  a wealth  of  information  is  available  to  the 

* System  about  the  configuration  to  be  analyzed.  The  entire  hierarchy  of  data 
beginning  with  the  named  set  and  ending,  after  a variable  number  of  hierarchical 
levels  of  subsets,  in  data-items  or  arrays  of  data-items  conveys  information 
about  the  configuration  to  be  analyzed  and  about  the  software  elements  that  will 
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be  called  to  perform  the  analysis.  If  the  configuration  is  a rotor  on  a whirl  stand, 
then  there  is  no  need  to  call  on  software  elements  that  simulate  landing  gear;  or 

I 

if  the  configuration  is  a multiple-rotor  helicopter,  then  the  software  element  that 
models  the  main  rotor  must  be  executed  a number  of  times  equal  to  the  number 
of  rotors.  The  specification  of  this  set  name  will  automatically  cause  the  proper 
software  elements  to  be  executed. 

The  next  statements  in  the  Configuration  Specification  Section  specify  the  re- 
placement of  any  of  the  subsets  of  the  aforementioned  set  with  another  set  of  • 

the  same  type  in  the  Master  Data  Base.  To  accomplish  this  replacement,  a 
set  specification  statement  of  the  same  form  as  described  above  is  used,  sep- 
arated from  a previous  set  specification  statement  by  a comma.  An  example 
of  set  replacement  follows: 

CONFIGURATION: 

SRH  = UH60A, 

ROTOR  = ZZ435 

This  example  causes  the  single-rotor  helicopter  described  in  UH60A  to  be  ana- 
lyzed with  its  rotor  replaced  by  ZZ435.  The  System  verifies  that  the  set  of 
type  SRH  contains  a subset  of  type  ROTOR  and  that  the  new  set,  ZZ435,  is  a 
set  of  type  ROTOR.  Any  discrepancy  in  set  types  causes  the  System  to  produce 
a user  input  diagnostic  message. 

For  some  types  of  configuration,  there  is  more  than  one  subset  of  a given 
type.  For  example,  a configuration  of  type  SRH  (single  rotor  helicopter)  has 
two  subsets  of  type  ROTOR  (one  for  the  main  rotor  and  one  for  the  tail  rotor). 

This  situation  might  make  it  impossible  for  the  System  to  identify  the  subset  to 
be  replaced  in  the  preceding  example.  To  prevent  the  ambiguity,  any  subsets 

* 

of  a configuration  that  have  identical  types  must  have  the  types  qualified  to  make 
the  subsets  identifiable  by  qualified  type.  In  the  example  of  the  configuration 
of  type  SRH,  the  two  subsets  of  type  ROTOR  are  distinguished  by  qualifying 
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their  types  as  ROTOR(MAIN)  and  ROTOR(TAIL).  The  foregoing  example  should 
have  been  written: 

i CONFIGURATION: 

* SRH  = UH60A, 

ROTOR  (MAIN)  = ZZ435 

t 

The  example  now  specifies  that  the  subset  of  type  ROTOR(MAIN)  is  to  be  re- 
placed by  set  ZZ435,  which  must  have  type  ROTOR. 

The  following  are  some  examples  of  the  Configuration  Specification  Section  as 
described  to  this  point: 

Example  I : 

CONFIGURATION: 

SRH  = UH60A 
, ROTOR  (MAIN)  = ZZ435 

This  example  is  the  same  as  that  described  previously.  The  configuration  to 
be  analyzed  is  contained  in  set  UH60A,  which  must  be  of  type  SRH.  The  only 
change  to  the  data  as  contained  in  set  UH60A  in  the  Master  Data  Base  is  that 
the  data  for  the  main  rotor  is  replaced  by  the  rotor  data  contained  in  set  ZZ435 

in  the  Master  Data  Base,  which  must  be  of  type  ROTOR.  The  replacement  r 

statement  for  the  rotor  and  the  comma  separating  this  statement  from  the  pre- 
vious statement  are  on  a separate  card  so  that  by  removing  that  one  card  the 

- J 

configuration  can  be  changed  to  that  contained  in  set  UH60A  with  no  rotor  re- 
( placement.  -i 

Example  2: 

CONFIGURATION: 

V 

MRWR  = ROTEST23 

In  this  example,  the  set  named  ROTEST23,  which  is  of  type  MRWR  (main  rotor 
on  whirl  rig)  is  the  configuration  to  be  analyzed. 
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Example  3: 

CONFIGURATION:  , 

TRH  = XPER70, 

ROTOR(  FORWARD)  = XRTR15, 

ROTO  R(  A FT)  = XRTR15, 

» 

ROTORCOUP  = ROTOR- TO-ROTOR- INTERFERENCE-15 

In  this  example,  the  configuration  to  be  analyzed  is  of  type  TRH  (tandem  rotor 
helicopter).  The  set  describing  the  configuration  is  named  XPER70.  Both 

' i 

rotors  are  replaced  by  set  XRTR15,  which  is  of  type  ROTOR,  and  the  set  named 
ROTOR-TO-ROTOR-INTERFERENCE-15,  which  is  of  type  ROTORCOUP,  contains 
the  data  for  rotor- to -rotor  coupling. 

Thus  far,  the  examples  provided  have  assumed  that  a single  name  is  enough  to 
uniquely  identify  a set  in  the  Master  Data  Base.  In  fact,  in  order  to  identify  a 

• 7 

set  in  the  Master  Data  Base,  it  is  necessary  to  name  the  sets  in  the  hierarchy 
containing  the  set  to  be  identified;  for  example, 

UH60A.  UH60A  EN 

This  example  identifies  set  UH60AEN  as  a subset  of  set  UH60A.  Any  of  the 
set  names  in  the  examples  given  above  must  appear  in  this  form  unless  they 
are  at  the  highest  level  of  the  hierarchy.  Thus,  example  3 (above)  might  ap- 
pear as 

' r 

CONFIGURATION; 

TRH  = XPER70,  x 

ROTOR  (FORWARD)  = XPER53.  XRTR15, 

ROTOR  (A FT)  = XPER53.  XRTR15, 

ROTORCOUP  = ROTOR-TO-ROTOR-INTERFERENCE-15 
In  this  example,  set  XRTR15  is  a subset  of  set  XPER53. 
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The  same  type  of  ambiguity  might  occur  in  specifying  the  type  of  a set  to  be 
replaced  if,  for  example,  a blade  of  a rotor  of  a tandem-rotor  helicopter  con- 
figuration is  to  be  replaced.  In  this,  example,  there  are  two  rotors  and  mul- 
tiple blades  per  rotor  so  that  to  specify  which  blade  of  which  rotor  is  to  be 
replaced  requires  the  following: 

ROTOR(  FORWARD).  BLADE(C)  = XBLAD5 

In  this  example,  XBLAD5  is  a set  at  the  highest  level  of  the  hierarchy  in  the 
Master  Data  Base  that  is  to  be  used  as  a replacement  for  a blade  of  the  forward 
rotor  in  this  configuration. 

To  this  point,  the  discussion  has  been  limited  to  sets  and  subsets.  We  now  turn 
our  attention  to  the  arrays  and  data-items  of  which  sets  are  composed.  The  state- 
ments described  below  are  called  value  specification  statements.  They  enable 
the  System  user  to  set  the  values  of  data-items  or  arrays  for  this  case.  A yalue 
specification  statement  has  the  following  form:  data-item  identification,  equals 
sign,  value.  Just  as  for  set  names  and  types,  it  is  possible  for  duplicate  data- 
item  names  to  occur  in  different  sets.  For  example,  angle  of  attack  for  different 
aerodynamic  surfaces  is  designated  ALPHA  in  the  sets  describing  the  different 
aerodynamic  surfaces.  To  identify  the  data-item,  it  is  necessary  to  precede  its 
name  with  the  types  of  the  sets  containing  the  data-item.  For  example, 

SRH.  ROTOR(TAIL).  XTR  = 12.48 

means  that  the  X coordinate  of  the  location  of  the  tail  rotor  is  12. 48  meters 
for  this  case  (assuming  METRIC  UNITS  were  specified  in  the  Case  Specification 
Section). 

For  another  example, 

TRA.  ASURF(G).  ALPHAG  = 0.05 

indicates  that  the  geometric  angle  of  attack  for  aerodynamic  surface  G of  a tilt- 
rotor  aircraft  is  0. 05  radian  for  this  case. 
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A data-item  contained  in  an  array  is  identified  by  the  array  name  followed  by 
indexes  in  parentheses.  For  example, 

SRH.  ROTOR(MAIN).  STRUCPROP.  EIC(IO)  = 2.23E8 

means  that  the  tenth  data-item  of  the  chordwise  bending  stiffness  array,  which 

8 2 

is  in  the  indicated  set  hierarchy,  is  to  be  set  to  2.23  X 10  pound-inches  . 

In  another  example, 

SRH.  AIRFRAME.  FUSE.  OMEGAF(3)  = 13.7 

means  that  the  third  fuselage  natural  frequency  is  to  be  set  to  13.7  hertz. 

It  is  in  the  value  specification  statements  that  the  question  of  units  becomes 
important.  The  units  specified  in  the  Case  Specification  Section  are  assumed 
for  all  values  unless  otherwise  specified  in  the  value  specification  statement. 
The  value  on  the  right  of  the  equals  sign  may  be  followed  by  a units  designation 
to  indicate  the  units  of  this  particular  value.  For  example,  the  geometric  angle 
of  attack  specified  above  might  instead  be  given  in  degrees,  as  follows: 

TRA.  ASURFG.  ALPHAG  = 3 DEG 

It  is  possible  to  specify  an  entire  configuration  in  user  input  without  reference 
to  the  Master  Data  Base  by  omitting  the  set  specification  statements  from  the 
Configuration  Specification  Section  and  using  only  value  specification  state- 
ments to  set  all  the  initial  values  required  for  the  analysis.  If  it  is  necessary 
to  specify  large  configurations  frequently  without  reference  to  the  Master  Data 
Base,  the  use  of  the  data-item  identification  on  the  card  in  addition  to  the  value 
adds  bulk  to  the  user  input  deck.  This  approach  has  been  taken  here  in  spite 
of  that  disadvantage  because  of  its  overriding  advantages.  Because  each  value 
is  separately  identified,  the  order  of  cards  is  unimportant  provided  they  are 
in  the  correct  section  of  user  input.  The  identification  of  each  value  further 
adds  documentation  to  the  user  input  deck,  which  reduces  errors  in  its  creation 
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and  in  any  changes  required  later.  In  the  final  design  of  the  user  input,  abbre- 
viations will  be  defined  that  will  alleviate  the  bulk  problem  by  allowing  shorter 
ways  to  specify  values  (i.e.  , by  setting  an  entire  array  in  a single  statement). 
These  measures  will  increase  the  advantages  of  the  approach  proposed  here. 

In  summary,  the  physical  configuration  to  be  analyzed  is  specified  in  the  Con- 
figuration Specification  Section  of  user  input.  The  first  statement  of  the  Con- 
figuration Specification  Section  is  the  word  CONFIGURATION  followed  by  a 
colon.  The  next  statements  of  the  section  are  set  specification  statements  if 
the  configuration  is  in  the  Master  Data  Base.  The  final  statements  of  the  sec- 
tion are  value  specification  statements  if  any  values  in  the  configuration  are  to 
be  specified  in  user  input.  The  sets  specified  in  set  specification  statements 
are  moved  from  the  Master  Data  Base  to  the  Run  Data  Base,  and  all  values 
named  in  value  specification  statements  are  set  to  the  values  given. 

4.3.3  Conditions  Specification  Section 

The  Conditions  Specification  Section  describes  the  maneuvers,  conditions, 
and  operating  regimes  to  be  applied  to  the  configuration  for  the  analysis.  The 
first  statement  of  the  Conditions  Specifications  Section  is  as  follows: 

CONDITIONS: 

The  remainder  of  the  Conditions  Specification  Section  is  identical  in  form  to 
the  Configuration  Specification  Section  described  above;  that  is,  sets  in  the 
Master  Data  Base  describing  the  maneuvers,  conditions,  and  operating  re- 
gimes are  selected  for  inclusion  in  the  Run  Data  Base  using  the  same  form  of 
set  specification  statement  as  described  above;  and  values  in  those  sets  are 
changed  by  the  use  of  value  specification  statements,  which  have  the  same  form 
as  the  value  specification  statement  described  above. 

As  a minimum,  the  conditions  for  an  analysis  must  be  specified.  If  no  maneu- 
vers are  specified,  a steady-state  operation  is  assumed.  If  maneuvers  are 
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specified,  System  Commands  that  name  appropriate  software  elements  from  the 

Maneuver  Subsystem  will  be  included  in  the  Sequence  Control  Table.  i 

It  is  possible  to  perforin  analyses  with  no  more  in  user  input  than  the  Case 
Specification  Section,  the  Configuration  Specification  Section,  and  the  Condi- 
tions Specification  Section.  The  User  Input  Package,  which  reads  and  processes  » 

user  input,  uses  the  information  in  the  Configuration  Specification  Section  and 
the  Conditions  Specification  Section  to  construct  a Run  Data  Base  (described  in 
Section  4.6).  The  sets  specified  in  set  specification  statements  are  moved 
from  the  Master  Data  Base  to  the  Run  Data  Base,  and  all  values  named  in 
value  specification  statements  are  set  to  the  values  given.  The  configuration 
thus  specified,  together  with  information  from  the  Case  Specification  Section 
as  to  aircraft  life  cycle  phase  and  aircraft  technical  characteristic,  indicates 
which  subsequences  of  System  Commands  (see  Section  2. 5)  are  to  be  selected 
from  the  Master  Command  File  and  concatenated  to  form  the  sequence  of  System 
Commands  in  the  Sequence  Control  Table.  Section  4. 5 describes  System  Com- 
mands. ’ 

4.3.4  Failure/Damage  Specification  Section 

The  Failure/Damage  Specification  Section  specifies  failure  or  damage  effects  f 

that  are  to  apply  to  the  configuration  for  this  case.  If  no  failure  or  damage 
effects  are  applicable  for  this  case,  then  the  Failure/Damage  Specification 

* r 

Section  will  not  appear  in  user  input.  The  first  statement  of  the  Failure/ 

Damage  Specification  Section  is  as  follows: 

FAILUREDAMAGE: 

The  remainder  of  the  Failure/Damage  Specification  Section  is  identical  in  form 
to  the  Configuration  Specification  Section  described  above;  that  is,  sets  in  the 
Master  Data  Base  describing  the  failure  or  damage  effects  for  this  case  are 
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selected  for  inclusion  in  the  Run  Data  Base  using  the  same  form  of  set  specifi- 
cation statement,  and  values  of  data  elements  in  those  sets  are  changed  by  the  use  i 

of  value  specification  statements. 

The  result  of  failure/damage  effects  on  the  creation  of  the  sequence  of  System 
Commands  in  the  Sequence  Control  Table  is  to  create  a separate  subsequence 
of  System  Commands.  This  separate  subsequence  is  given  control  at  the  point 
in  the  analysis  when  the  failure  or  damage  occurs.  The  flow  of  control  is 
generally  unchanged,  but  the  flow  of  data  as  specified  in  the  System  Command 
subsequence  will  change  as  a result  of  the  failure  or  damage. 

4.3.5  Options  Specification  Section 

The  Options  Specification  Section  describes  the  options  the  user  wishes  to 
exercise  for  this  case.  The  Options  Specification  Section  may  be  omitted  if  the 
default  options  are  appropriate  for  this  run.  The  first  statement  of  the  Options 
Specification  Section  is  as  follows: 

OPTIONS: 

The  Options  Specification  Section  is  divided  into  the  following  subsections,  each  of 
which  specifies  a different  type  of  option: 

f 

1.  Print  Specification  Subsection 

2.  Plot  Specification  Subsection 

3.  Analysis  Technique  Specification  Subsection 

i 

4.  Diagnostic  Specification  Subsection 

5.  Checkpoint/Restart  Subsection 

The  Print  Specification  Subsection  specifies  quantities  to  be  printed  in  addition 
to  those  printed  by  default  and  the  format  in  which  they  are  to  be  printed.  In 
addition,  this  subsection  specifies  quantities  normally  printed  by  default  that 
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the  user  chooses  not  to  be  printed  for  this  case.  The  forms  of  the  statements 
for  this  subsection  are  as  follows: 

PRINT  REPORT  a 

PRINT  INTERMEDIATE  IN  FORMAT  b: 

data  element,  ...  , data  element  • 

PRINT  FINAL  IN  FORMAT  c: 

data  element,  ...  , data  element 

DO  NOT  PRINT: 

data  element,  . . . , data  element 

FORMAT  d: 

format  definition  statement 

The  PRINT  statements  specify  that  certain  data  elements  are  to  be  printed  that 
would  otherwise  not  be  printed.  The  word  REPORT  followed  by  an  identification 
refers  to  a collection  of  data  elements  that  are  normally  printed  together  in  an 
internally  defined  format.  The  word  INTERMEDIATE  means  that  the  specified 
data  elements  are  to  be  printed  whenever  they  are  produced  by  a software  ele- 
ment during  the  analysis.  The  word  FINAL  means  that  the  specified  data  ele- 
ments are  to  be  printed  at  the  end  of  the  analysis  for  this  case.  If  neither  word 
appears,  FINAL  is  assumed.  Several  print  formats  are  internally  defined  in  the 
System.  If  these  formats  are  used,  the  FORMAT  statement  may  be  omitted.  A 
print  format  not  internally  defined  in  the  System  may  be  defined  in  the  use  of  the 
FORMAT  statement.  Examples  of  the  use  of  these  statements  are  as  follows:  » 

PRINT  IN  FORMAT  4: 

LOADS.  AUTOCORR.  AIRFRAME.  NODE(5) 


means  print  the  autocorrelation  of  the  vibration  of  node  point  5 on  the  airframe 
in  format  4 (an  internally  defined  format)  at  the  end  of  processing  for  this  case. 


DO  NOT  PRINT: 

AEROSTAB.  EIGENVECTORS.  INERTIAFORCES 
AEROSTAB.  EIGENVECTORS.  AERO  FORCES 

means  suppress  the  printing  of  the  inertia  forces  and  aerodynamic  forces  cal- 
culated as  the  result  of  the  analysis. 

The  Plot  Specification  Subsection  specifies  quantities  to  be  plotted  and  the  format 
in  which  they  are  to  be  plotted.  The  forms  of  the  statements  for  this  subsection 
are  as  follows: 

PLOT  INTERMEDIATE  IN  FORMAT  x: 
array,  ....  array 

PLOT  FINAL  IN  FORMAT  y: 
array,  . . . , array 

FORMAT  z: 

format  definition  statement 

The  two  PLOT  statements  have  meanings  similar  to  the  two  PRINT  statements 
in  the  Print  Specification  Subsection.  Just  as  for  print  formats,  the  System 
has  several  internally  defined  plot  formats  for  which  no  FORMAT  statement  is 
necessary.  Other  formats  can  be  defined  in  user  input  by  means  of  the  Format 
Definition  Statement  defined  by  the  user.  The  effect  of  the  Plot  Specification 
Subsection  is  to  produce  device- independent  plot  files.  The  device-independent 
plot  files  can  be  processed  during  the  analysis  to  produce  a plot  for  a specific 
device  or  they  can  be  subsequently  processed  to  produce  plots  on  off-line  devices. 

The  Analysis  Technique  Specification  Subsection  specifies  which  of  several  al- 
ternative analysis  techniques  the  System  is  to  use  in  performing  the  analysis. 

The  statements  in  this  subsection  are  a list  of  keywords.  The  appearance  of 
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a keyword  specines  mai  a particular  analysis  technique  is  to  be  used.  The 
keywords  that  are  currently  defined  and  their  meanings  are  as  follows: 

Keyword  Meaning 

MODAL 

DIRECT 

TRANSFER 

UNCOUPLED 
FLYTOTRIM 
FLOQUET 

LINSTAB 

THEODORSEN 

CARTA 

This  subsection,  along  with  the  Case  Specification  Section  and  the  Configuration 
Specification  Section,  affects  the  construction  of  the  Sequence  Control  Table. 
The  analysis  technique  to  be  used  is  another  determining  factor  used  by  the 
User  Input  Package  to  select  subsequences  of  System  Commands  from  the 
Master  Command  File  and  construct  the  sequence  of  System  Commands  in  the 
System  Control  Table. 

The  Diagnostic  Specification  Subsection  specifies  the  options  to  be  used  for 
producing  diagnostic  messages  for  this  case.  The  options  are  expressed  as 


Use  the  modal  method  for  the  solution  of  dynamic 

equations  * 

Use  the  direct  method  for  the  solution  of  dynamic 
equations 

Use  the  transfer  matrix  method  for  the  solution  . 

of  dynamic  equations 

Iterate  to  trim  using  uncoupled  equations 

Use  an  autopilot  to  fly  the  aircraft  to  trim 

Use  Floquet  theory  to  solve  for  aeroelastic  sta- 
bility 

Use  constant  coefficient  equations  to  solve  for 
aeroelastic  stability 

Use  the  Theodorsen  method  for  unsteady  aero- 
dynamic calculations 

Use  the  Carta  method  for  unsteady  aerodynamic 
calculations 
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short  statements  which  are  for  the  most  part  self-explanatory.  The  following 
statements  may  be  used: 

I 

SUPPRESS  INFORMATIVE  DIAGNOSTICS 
SUPPRESS  WARNING  DIAGNOSTICS 
SUPPRESS  DIAGNOSTICS 
STOP  IF  ERROR  IN  INPUT 
WRITE  DIAGNOSTICS  ON  FILE  a 

The  first  two  statements  are  self-explanatory.  The  third  statement  is  a shorter 
way  to  achieve  the  effect  of  both  the  first  and  second  statements.  There  is  no 
option  to  suppress  fatal  diagnostic  messages.  The  fourth  statement  causes 
processing  to  halt  after  checking  the  input  if  any  errors  are  discovered  in  the 
input.  (This  option  affects  only  "warning"  errors.  Fatal  errors  always  stop 
processing. ) The  last  statement  causes  the  diagnostic  messages  to  be  written 
on  a file  which  may  be  examined  after  the  analysis  run. 

An  additional  capability  that  may  be  exercised  in  the  Diagnostic  Specification 
Subsection  is  to  plot  graphable  input.  The  statement  that  uses  this  function  is 
similar  to  the  PLOT  statements  discussed  in  the  Plot  Specification  Subsection: 

PLOT  INPUT  IN  FORMAT  x: 

array,  array,  . . . , array 

FORMAT  y: 

. 

format  definition  statement  , 

As  before,  some  plot  formats  are  internally  defined  in  the  System,  but  if  a 
different  format  is  desired,  it  may  be  defined  in  user  input. 
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The  Checkpoint/Restart  Subsection  specifies  the  use  of  checkpoint  or  restart  func- 
tions for  this  case.  The  statements  which  may  be  used  in  this  section  are  as 
follows: 

CHECKPOINT  ON  FILE  b 

RESTART  FROM  CHECKPOINT  n ON  FILE  c 

The  occurrence  of  the  CHECKPOINT  statement  causes  the  checkpoint  System 
Commands  in  the  Sequence  Control  Table  to  be  executed  for  this  case.  Each 
time  a checkpoint  is  taken,  it  is  given  an  identification  by  the  System.  The 
checkpoint  identification  is  included  in  user  output  and  is  used  in  the  RESTART 
statement  as  shown  above  if  restart  from  that  checkrc'nt  is  desired  in  a sub- 
sequent run. 

The  occurrence  of  the  RESTART  statement  causes  the  Run  Data  Base  and  the 
Sequence  Control  Table  to  be  established  from  the  specified  checkpoint. 

Changes  are  then  made  to  the  Run  Data  Base  and  Sequence  Control  Table  based 
on  user  input. 

4.3.6  Accuracy  Assessment  Specification  Section 

The  Accuracy  Assessment  Specification  Section  specifies  the  output  data  ele- 
ments to  be  assessed  for  accuracy,  the  input  variables  to  be  varied,  and  the 
range  of  variation.  This  section  also  contains  (a)  data  against  which  System  re- 
sults are  to  be  compared  and  (b)  the  error  in  that  data. 

The  occurrence  of  the  Accuracy  Assessment  Specification  Section  in  the  user 
input  causes  the  User  Input  Package  to  create  a sequence  of  System  Commands 
for  performing  accuracy  assessment. 

4.4  MASTER  COMMAND  FILE 

The  Master  Command  File  contains  subsequences  of  System  Commands  for  use 
by  the  User  Input  Package  in  creating  the  sequence  of  System  Commands  to  control 
a particular  analysis  run.  System  Commands  are  described  in  Section  4. 5.  The 
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Master  Command  File  is  changed  only  by  an  authorized  person  using  the  Data  Base 
Support  Package  of  the  Support  Complex. 

The  Sequence  Control  Table  is  a table  internal  to  the  System  that  contains  the  se- 
quence of  System  Commands  that  specifies  the  actions  to  be  taken  by  the  System  in 
performing  an  analysis.  The  User  Input  Package  creates  the  Sequence  Control 
Table  from  subsequences  of  System  Commands  in  the  Master  Command  File  based 
on  information  in  user  input. 

The  overall  sequence  of  System  Commands  to  be  included  in  the  Sequence  Con- 
trol Table  is  determined  by  the  combination  of  aircraft  life  cycle  phase,  air- 
craft technical  characteristic,  the  existence  (or  nonexistence)  of  maneuvers, 
and  the  existence  (or  nonexistence)  of  failure/damage  effects  in  user  input. 

The  selection  of  small  groups  of  System  Commands  to  be  included  in  the  overall 
sequence  is  determined  by  the  configuration  to  be  analyzed  (from  the  Master 
Data  Base  as  selected  and  modified  by  user  input)  and  by  the  analysis  technique 
and  other  options  selected  by  user  input.  Examples  of  System  Command  Se- 
quences were  shown  in  graphical  form  in  Section  2.  5. 

The  Sequence  Control  Package  of  the  Executive  Component  reads  the  System  Com- 
mands from  the  Sequence  Control  Table  during  the  processing  phase  and  calls  the 
proper  software  element  to  perform  the  action  specified  by  each  System  Command. 

4.5  SYSTEM  COMMANDS 

Sequences  of  System  Commands  appear  in  the  Master  Command  File  and  in  the 
Sequence  Control  Table.  Sequences  of  System  Commands  control  the  execution 
and  data  flow  during  the  processing  phase  of  an  analysis  run.  The  reason  for 
using  System  Commands  to  direct  the  System  through  the  steps  required  to 
perform  an  analysis  is  to  allow  the  System  the  flexibility  to  perform  many 
different  analyses  by  changing  only  the  sequence  of  System  Commands.  The 
sequence  of  System  Commands  controlling  an  analysis  is  normally  created  and 
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put  in  the  Sequence  Control  Table  by  the  User  Input  Package  based  on  a descrip- 
tion of  the  analysis  contained  in  user  input,  as  described  in  Section  4. 3.  The  Sys- 
tem can  also  accept  user  input  directly  in  the  form  of  System  Commands  as 
described  below.  The  user  of  this  form  of  input  (a  methods  developer  is  a likely 
user  of  this  form  of  input)  is  required  to  know  more  about  the  internal  design  of 
the  System  than  is  the  user  of  the  more  conventional  user  input  described  in  Sec- 
tion 4.3;  furthermore,  there  are  fewer  internal  System  checks  for  errors  in 
such  input. 

System  Commands  are  of  two  types:  execution  and  sequence  control. 

An  execution  command  contains  the  name  of  the  software  element  to  be  executed 
and  the  input  data  elements  and  the  output  data  elements  to  be  used  by  the  soft- 
ware element  for  this  execution.  Upon  encountering  an  execution  command,  the 
Sequence  Control  Package  (which  is  responsible  for  the  order  of  execution  of  Sys- 
tem Commands)  calls  the  Run-Time  Control  Package  for  execution  of  the  software 
element  named  in  the  execution  command.  The  Run-Time  Control  Package  brings 
the  named  software  element  into  memory  (if  it  is  not  present),  makes  the  input 
data  elements  available  from  the  Run  Data  Base,  and  transfers  control  to  the 
named  software  element.  Upon  completion  of  execution,  the  named  software  ele- 
ment returns  control  to  the  Run-Time  Control  Package,  which  stores  the  output 
data  elements  in  the  Run  Data  Base. 

A sequence  control  command  provides  the  capability  to  control  the  sequence  in 
which  software  elements  are  invoked  in  the  System/ Command  Sequence.  There 


are  three  forms  of  sequence  control  commands: 

% 

1. 

IF-THEN-ELSE 

2. 

DO- WHILE 

3. 

STOP 

• t 
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The  IF-THEN- ELSE  form  of  sequence  control  command  has  three  separate 
System  Commands  that  together  perform  its  function: 

1.  IF  Command 

2.  ELSE  Command 

3.  END1F  Command 

The  IF  Command  contains  a condition  that  has  a value  of  TRUE  or  FALSE. 

The  condition  is  a relationship  between  variables  or  expressions.  If  the  value 
is  TRUE,  the  sequence  of  command  execution  continues  with  the  next  System 
Command.  If  the  value  is  FALSE,  the  sequence  of  command  execution  con- 
tinues with  the  ELSE  Command  or,  if  the  ELSE  Command  is  omitted,  with  the 
ENDIF  Command. 

The  ELSE  Command  appears  optionally  after  an  IF  Command.  The  value  of 
the  condition  that  was  part  of  the  IF  Command  determines  the  action  to  be  taken 
by  the  ELSE  Command.  If  the  value  is  TRUE,  the  System  Commands  between 
the  IF  Command  and  the  ELSE  Command  have  been  executed,  and  the  effect  of 
the  ELSE  Command  is  to  cause  the  sequence  of  command  execution  to  continue 
from  the  ENDIF  Command.  If  the  value  is  FALSE,  the  ELSE  Command  causes 
the  sequence  of  command  execution  to  continue  at  the  System  Command  imme- 
diately following  the  ELSE  Command. 

The  ENDIF  Command  must  always  follow  an  IF  Command  regardless  of  whether 
or  not  the  ELSE  Command  is  used.  The  purpose  of  the  ENDIF  Command  is  to 
mark  the  place  in  the  System  Command  Sequence  at  which  command  execution 
is  to  continue  regardless  of  the  effects  of  the  IF  Command  or  the  ELSE  Com- 
mand. The  effect  of  the  ENDIF  Command  is  to  cause  the  sequence  of  command 
execution  to  continue  with  the  next  System  Command. 

I 
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The  DO-WHILE  form  of  Sequence  Control  Command  has  two  separate  System 
Commands  that  together  perform  its  function: 

| 

1.  WHILE  Command 

2.  ENDDO  Command 

The  WHILE  Command  contains  a condition  identical  in  form  to  the  condition  in 
the  IF  Command.  This  condition  can  have  a value  of  TRUE  or  FALSE.  If  the 
value  is  TRUE,  the  sequence  of  command  execution  continues  with  the  next 
System  Command.  If  the  value  is  FALSE,  the  sequence  of  command  execution 
continues  with  the  System  Command  following  the  ENDDO  Command. 

The  ENDDO  Command  must  always  follow  a WHILE  Command.  The  ENDDO 
Command  causes  the  sequence  of  command  execution  to  continue  with  the  asso- 
ciated WHILE  Command. 

The  STOP  Command  causes  System  Command  execution  to  stop.  Control  is 
transferred  either  to  the  User  Output  Package  of  the  User  Interface  Subsystem 
for  printing  or  plotting  the  results  of  the  analysis  or  to  the  user  at  an  interactive 
terminal. 

4. 6 RUN  DATA  BASE 

At  the  end  of  the  input  phase,  the  Run  Data  Base  contains  the  initial  descriptions 
of  aircraft  components;  other  analysis  components;  coupling  of  components;  ma- 
neuvers, conditions,  and  operating  regimes;  and  failure /damage  effects  required 

as  input  for  a single  analysis  run.  During  the  processing  phase,  the  Run  Data  ‘ 

Base  contains  intermediate  results  produced  by  software  elements  during  an  , 

analysis  run. 

The  organization  of  sets  of  data  that  exist  at  the  beginning  of  the  processing 
phase  of  an  analysis  run  is  the  same  as  their  organization  in  the  Master  Data 
Base.  For  any  particular  analysis  run,  only  those  sets  required  for  the  analysis 
are  contained  In  the  Run  Data  Base. 


The  User  Input  Package  creates  the  input  sets  in  the  Run  Data  Base  and  sets  their 
values  from  the  Master  Data  Base  and  from  user  input.  The  User  Input  Package 

also  creates  the  sequence  of  System  Commands  in  the  Sequence  Control  Table  i 

from  commands  in  the  Master  Command  File  based  on  information  in  user  input 
and  the  Master  Data  Base.  The  sequence  of  System  Commands  to  be  executed 
specifies  the  data  required  by,  and  produced  by,  the  software  elements  to  be 
executed.  From  this  information  the  User  Input  Package  defines  the  sets  in 
the  Run  Data  Base  that  will  hold  intermediate  results  for  this  run.  The  defini- 
tion of  all  sets  to  be  used  in  this  analysis  run,  including  the  location  of  each 
set,  is  contained  in  a dictionary  for  the  Run  Data  Base.  The  Run  Data  Base 
dictionary  is  created  by  the  User  input  Package  and  is  used  by  software  ele- 
ments of  the  Data  Base  Management  Subsystem  to  store  or  retrieve  data  through- 
out the  analysis  run. 

4.7  OUTPUT  DATA 

Output  data  are  data  which  are  printed  or  plotted  or  displayed  on  a terminal 
for  interpretation  by  the  user.  Output  data  also  include  data  stored  in  files  on 
disk  or  tape  by  the  System  for  potential  later  use.  Data  for  external  models, 
checkpoint  data,  and  optionally,  diagnostic  messages  are  included  in  this  cate- 
gory. 

Output  data  are  produced  by  the  User  Output  Package,  by  the  Checkpoint  Package, 

* 

or  by  a software  element  in  the  External  Models  Interface  Subsystem.  Any  of 
these  software  elements  is  called  in  the  usual  way,  i.  e. , by  being  named  in  a 
System  Command  and  by  being  passed  input  data.  These  software  elements 
differ  from  the  typical  software  element  in  that  they  write  information  onto  files 
using  the  File  Management  Package  of  the  Operating  System  Service  Subsystem. 
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Printed  user  output  is  formatted  by  the  System  into  reports  that  are  compact 
and  easy  to  read.  The  format  of  the  printed  output  from  an  analysis  run  de- 

i 

pends  on  the  quantities  that  are  output  from  that  run,  which  depends  on  the 
options  specified  in  user  input.  The  units  for  the  printed  output  are  the  same 
as  the  units  of  the  input  quantities  in  the  Case  Specification  Section,  unless 
specified  otherwise  in  the  Options  Specification  Section.  Regardless  of  the 
format  and  quantity  of  the  output  variables,  each  page  of  printed  output  has 
header  information  that  contains  the  title  of  this  analysis  run,  the  title  of  the 

■ 

case,  the  date  of  the  run,  the  page  number,  the  report  title,  and  column  head- 
ings if  the  output  is  arranged  in  columns. 

User  output  plots  may  be  in  the  form  of  X-Y  plots,  multivariable  plots,  contour 
maps,  or  three-dimensional  projections,  depending  on  the  variables  to  be  plotted 
and  on  user  requirements.  Regardless  of  the  form  of  the  plot  or  the  device  on 
which  it  is  made,  all  plots  contain  the  titles  of  the  analysis  run  and  case  that  pro- 
duced them  and  the  date.  The  variables  plotted  and  identified,  and  the  scale  of  the 
plot  is  shown. 

Checkpoint  data  are  stored  on  the  Checkpoint  File  by  the  Checkpoint  Package. 

The  sets,  arrays,  or  data-items  in  the  Run  Data  Base  that  have  been  changed 
since  the  last  call  on  the  Checkpoint  Package  are  written  on  the  Checkpoint  File. 

Upon  restart,  the  Run  Data  Base  can  be  restored  from  the  Checkpoint  File  to 
its  state  at  any  checkpoint  up  to  the  last  one  executed  so  that  the  packages  and 

* V 

subpackages  in  the  previous  analysis  run  that  were  required  to  obtain  the  state  , 

of  the  Run  Data  Base  need  not  be  executed. 

% 

4.  8 DIAGNOSTIC  MESSAGES 

Diagnostic  messages  from  the  System  are  of  three  types: 

1.  Graphs  of  input  data 

2.  User  Input  diagnostic  messages 

3.  Internal  System  diagnostic  messages 

I 
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Graphs  of  input  data  are  produced,  at  user  option,  from  data  in  the  Run  Data  Base 

at  the  end  of  the  input  phase.  These  graphs  are  produced  in  the  same  manner  and  , 

are  identical  in  form  to  the  user  output  plots  discussed  in  Section  4.7.  This  op- 
tion is  exercised  by  a statement  in  the  Option  Specification  Section  of  user  input, 
described  in  Section  4. 3. 5. 

User  input  diagnostic  messages  report  to  the  user  any  error  in  user  input  dis- 
covered by  the  System.  The  user  input  diagnostic  messages  also  report  to  the 
user  unusual  conditions  or  other  information  that  may  be  useful.  Most  errors 
in  user  input  will  be  discovered  in  the  input  phase,  but  some  errors  can  be  dis- 
covered only  in  the  processing  phase.  User  input  diagnostic  messages  are  of 
three  types: 

1.  Informative-reports  an  unusual  condition  or  other  useful  information 

2.  Warning — reports  an  error  in  input  that  may  not  be  serious  enough  to 
prevent  System  execution 

3.  Fatal — reports  an  error  that  prevents  System  execution 

The  form  of  a user  input  diagnostic  message  is  a clear,  English-language 
statement  of  the  error  or  condition  detected  in  terms  related  to  the  user  input. 

t' 

Internal  System  terminology  such  as  module  names  will  not  appear  in  user 
input  diagnostic  messages. 

t. 

Internal  System  diagnostic  messages  report  internal  logic  errors  in  the  System. 

Included  ds  part  of  the  message  is  any  information  collected  thus  far  by  the 
System  that  will  help  in  locating  and  correcting  the  System  error.  The  form 
of  an  internal  System  diagnostic  message  is  an  English-language  statement 
identifying  the  message  as  an  Internal  System  diagnostic  message  followed  by 
information  intended  to  be  used  in  the  error  correction  process.  Internal  Sys- 
tem diagnostic  messages  may  be  Informative,  warning,  or  fatal,  just  as  are 
user  input  diagnostic  messages. 

— te 
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SECTION  5 - DEVELOPMENT  PLAN 

| 

The  development  plan  overview  presented  in  this  section  summarizes  CSC's  cur- 
rent plan  for  the  development  of  the  First  Level  Release,  Second  Level  Release, 
and  Long  Range  System  capabilities  of  the  Second  Generation  Comprehensive 
Helicopter  Analysis  System.  This  plan  is  based  on  the  Baseline  Development  Plan 
for  the  Second  Generation  Comprehensive  Helicopter  Analysis  System,  CSC/ 

SD-78/6008,  hereinafter  called  the  Baseline  Development  Plan.  Because  of  the 
need  to  effectively  control  the  development  of  the  System,  CSC  recommends  that 
the  Government  require  the  Development  Phase  Contractor  to  deliver,  as  a Con- 
tract Data  Requirements  List  (CDRL)  item  2 months  after  Development  Phase 
contract  award,  a System  Development  Plan.  The  System  Development  Plan  would 
be  an  evolutionary  conclusion  to  the  planning  activities  of  the  Predesign  Phase  and 
to  the  source  selection  process  that  culminates  with  the  award  of  the  Development 
Phase  contract  to  the  Development  Phase  Contractor.  CSC  envisions  that  the  Sys- 
tem Development  Plan  evolves  from  the  Baseline  Development  Plan;  defines  the 
responsibilities  of  the  various  organizations  involved  in  System  development;  and 
is  maintained  as  a baseline  document  so  that  up-to-date  information  about  all  tech- 
nical and  management  aspects  of  the  System's  development  are  available  to  all 
concerned  Government  and  industry  organizations. 

This  development  plan  addresses  the  19  items  presented  in  Task  1(e)  of  the  State-  V 

ment  of  Work  of  the  contract.  1 

Section  5.1,  Organization  and  Responsibilities,  defines  the  organizational  structure 
and  the  responsibilities  of  the  Applied  Technology  Laboratory,  the  prime  contrac- 
tor software  firm  (called  the  Development  Phase  contractor),  the  helicopter  firm 
team  member  (called  the  integrated  team  member  subcontractor),  the  CPCI  sub- 
contractors, the  Government/Industry  User  Community,  the  Government/Industry 
Working  Group,  and  Technical  Advisory  Group.  This  section  is  based  on  the  Or- 
ganization Plan  of  the  Baseline  Development  Plan. 
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Section  5.2,  Management  Plans,  is  made  up  of  the  following  subplans:  Development 
Control  Plan,  Work  Management  Plan,  Communication  Plan,  Internal  Review  and 
Reporting  Plan,  Configuration  Management  Plan,  and  Documentation  Management 
Plan.  These  subplans  are  based  on  similarly  titled  subplans  in  the  Baseline  De- 
velopment Plan. 

Section  5.3,  Technical  Plans,  is  made  up  of  three  major  subplans  (Quality  Assur- 
ance Plan,  Testing  Plan,  and  Documentation  Plan)  and  five  subordinate  subplans 
(Data  Processing  Facility  Plan,  Data  Management  Plan,  System  Installation  and 
Release  Plan,  Training  Plan,  and  Maintenance  Plan).  These  subplans  are  based 
on  similarly  titled  subplans  in  the  Baseline  Development  Plan. 

Section  5.4,  Implementation  Plan,  presents  a time-phased  plan  for  developing  the 
First  Level  Release  and  the  Second  Level  Release  of  the  System. 

Table  3 shows  the  relationship  of  the  19  items  of  Task  1(e)  of  the  Statement  of  Work 
to  the  subplans  listed  above. 

5. 1 ORGANIZATION  AND  RESPONSIBILITIES 

The  multiorganization  (Applied  Technology  Laboratory,  Development  Phase 
Contractor,  integrated  team  member  subcontractor,  CPCI  subcontractors, 
Govemment/lndustry  User  Community,  Government/Industry  Working  Group, 
Technical  Advisory  Group)  environment  of  the  Development  Phase  makes  it  nec- 
essary to  define  and  adhere  to  clear  lines  of  authority  and  responsibility  and  ef- 
fective lines  of  communication.  The  nature  of  this  environment  and  a preliminary 
plan  for  defining  these  interfaces  are  presented  in  Section  5. 1. 1.  The  preliminary 
Project  organization  for  the  Development  Phase  is  presented  in  Section  5. 1.2 
where  the  responsibilities  of  the  Development  Phase  Contractor,  the  integrated 
team  member  subcontractor,  and  CPCI  subcontractors  are  presented  in  relation- 
ship to  the  technical  activities  associated  with  each  of  the  elements  of  the  planned 
Project  organization. 
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Table  3.  Allocation  of  the  19  Items  of  Paragraph  (e)  of  Task  I of  the  Statement  of 
Work  to  the  Subplans  of  the  Development  Plan  (1  of  3) 
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5.1.1  Development  Phase  Organizational  Environment 

The  Second  Generation  Comprehensive  Helicopter  Analysis  System  will  be  devel- 
oped in  a multiorganization  environment,  with  numerous  well-defined  interfaces 
required. 

The  overall  management  of  the  development  effort  is  the  responsibility  of  the 
Applied  Technology  Laboratory. 

The  Development  Phase  contractor,  expected  to  be  one  of  the  Predesign  Phase 
contractors,  is  responsible  for  the  following: 

• Designing  the  System 

• Identifying  CPCIs 

• Preparing  a Type  B5  Development  Specification  for  each  CPCI,  for 
both  First  Level  Release  and  Second  Level  Release  capabilities 

• Recommending  those  CPCIs  to  be  developed  by  the  Development 
Phase  Contractor  (in  conjunction,  possibly,  with  an  integrated 
team  member  subcontractor),  those  by  CPCI  subcontractors,  and 
those  to  be  Government -furnished,  based  on  the  premises  that  few, 
if  any,  First  Level  Release  CPCIs  will  be  Government-furnished 
and  few,  if  any,  Second  Level  Release  CPCIs  will  be  developed  by 

CPCI  subcontractors  t 

• Developing  those  CPCIs  approved  by  the  Contracting  Officer 

• Determining  that  each  CPCI  meets  the  requirements  and  quality 

assurance  provisions  of  its  Type  B5  Development  Specification 

• Integrating  all  CPCIs  into  the  System 

• Conducting  a functional  demonstration  of  the  System  to  demonstrate 
to  Government  and  industry  that  the  System  meets  the  requirements 
and  quality  assurance  provisions  of  the  Type  A System  Specification 
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Defining  a unified  documentation  approach  and  editing  documentation 
for  each  CPCI  to  promote  the  uniformly  high  standards  needed  for  the 
engineering  user  and  the  methods  developer 

Defining  and  implementing  a configuration  management  plan 


• Providing  training  and  maintenance  support  to  Government  and 
industry  users  during  the  initial  portion  of  the  Validation  Phase 


The  Govemment/Industry  Working  Group  and  the  Technical  Advisory  Group 
continue  their  Predesign  Phase  activities  in  advising  the  Government  project 
team. 

The  Government  project  team  monitors  the  development  of  the  System  in  detail 
down  to  the  level  of  a single  line  of  code  or  engineering  equation.  The  Government 
project  team  approves  all  Type  B5  Development  Specifications  produced  by  the 
Development  Phase  Contractor  for  each  CPCI.  In  addition,  the  Government  proj- 
ect team  participates  in  the  evaluation  of  and  exercises  selection  approval  of  sub- 
contractors for  CPCI  development.  The  Government  will  prepare  to  assume  full 
responsibility  for  the  System  during  the  Maintenance  Phase.  The  Government  will 
finalize  requirements  for,  and  sponsor  acquisition  of,  experimental  data  necessary 
to  determine  CPCI  and  System  level  accuracy. 

Interfaces  with  the  Government/industry  user  community  comme-'ce  with  the 
Validation  Phase,  which  begins  when  the  First  Level  Release  is  provided  to 
the  users.  The  objectives  of  the  Validation  Phase  are  to  establish  within  the 
* Government/industry  user  community  an  operational  capability  with  the  System, 

contribute  to  the  validation  of  the  accuracy  and  operating  cost  of  the  System, 
and  provide  inputs  from  the  user  community  to  the  Development  Phase  Contractor 
and  the  Government  project  team  to  maximize  user  orientation  of  the  System 
during  the  remainder  of  the  Development  Phase  and  during  the  Maintenance  Phase. 
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Helicopter  manufacturers  under  contract  to  the  Government  validate  the  appli- 
cability of  the  System  to  their  helicopter  types  by  correlation  with  experimental 
data.  (These  contracts  are  separate  from  the  Development  Phase  contract. ) 

Also  during  the  Validation  Phase,  these  helicopter  manufacturers,  along  with 
Government  users. 


• Achieve  an  operational  capability  with  the  System 

• Apply  the  System  to  current  rotary-wing  research  and  development 
efforts,  in  parallel  with  other  methods  of  analysis,  to  evaluate  the 
effectiveness  of  the  System 

• Identify  minor  errors  and  deficiencies,  determine  corrective  meas- 
ures, and  recommend  their  implementation 

• Identify  areas  where  the  System  can  be  enhanced  and  make  recom- 
mendations to  the  Government  project  team  that  the  System  be 
modified 


It  is  expected  that  information  associated  with  these  activities  will  be  transmitted 
to  the  Development  Phase  Contractor  by  the  Government.  Figure  36  summarizes 
the  formal  and  informal  lines  of  communication  among  the  organizations  involved. 

5.1.2  Project  Organization 

One  of  the  most  important  and  critical  characteristics  of  the  Project  organiza- 
tion is  the  organizational  capability  to  manage  and  carry  out  tasks  within  the 
work  breakdown  structure  (WBS)  that  it  is  assumed  will  be  a part  of  the  Statement 
of  Work  of  the  Development  Phase  Request  for  Quotation.  Although  the  tasks, 
subtasks,  and  lower  level  work  elements  of  the  WBS  are  not  presently  known, 
sufficient  information  has  been  provided  by  the  Government  for  CSC  to  propose  a 
Development  Phase  Project  organization  effectively  structured  to  meet  the  antic- 
ipated tasks  and  subtasks  in  the  Statement  of  Work.  This  project  organization  is 
presented  in  Figure  37. 
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The  Project  Manager's  objective  is  to  complete  the  Project  in  accordance  with 
the  Statement  of  Work,  the  specifications,  the  Contract  Data  Requirements  List, 
and  other  provisions  of  the  contract  and  within  the  budgetary  and  time  constraints 
of  the  contract.  In  other  words,  the  Project  Manager  is  completely  responsi- 
ble for  the  technical  and  financial  success  of  the  Project.  A detailed  discussion 
of  the  Project  Manager's  derived  responsibilities  and  authorities  that  are  corol- 
laries to  this  primary  responsibility  is  found  in  Section  5. 1.2.1.  The  Project 
Manager  is  assisted  by  the  Support  Services  staff,  which  performs  the  following 
administrative  services: 

• Assisting  the  Project  Manager  in  all  aspects  of  Project  administra- 
tion 

• Interfacing  with  the  CSC  service  organizations  to  ensure  effective 
and  timely  support 

• Aiding  the  Project  Manager  in  presentation  of  Project  statistical 
data 

• Providing  assistance  in  the  scheduling,  accounting,  and  control  of 
computer  resources 

• Providing  documentation  configuration  control  assistance 

• Providing  support  in  Project  scheduling  activities 

• Providing  administrative  assistance  with  subcontractors  and 
vendors 

The  Technical  Director  has  two  primary  responsibilities:  to  ensure  the  technical 
quality  of  the  Project's  technical  products  (source,  object,  and  executable  code 
and  documentation)  and  to  act  with  the  full  authority  of  the  Project  Manager  should 
the  Project  Manager  be  absent.  The  responsibilities  and  authorities  of  the  Tech- 
nical Director  are  described  in  more  detail  in  Section  5. 1.2.2. 
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Reporting  to  the  Technical  Director  are  three  line  organizations:  the  Technology 
Analysis  and  Design  Technical  Area,  the  Software  Technical  Area,  and  the  Prod- 
uct Assurance  Technical  Area.  The  primary  responsibility  of  the  Technology 
1 Analysis  and  Design  Technical  Area  is  to  produce  that  part  of  the  Type  B5  Develop- 

ment Specifications  associated  with  helicopter  and  mathematical  analysis  (the 
Technology  Component  CPCIs  of  the  Operational  Complex;  see  Section  2. 3. 1). 

Other  responsibilities  of  the  Technology  Analysis  and  Design  Technical  Area  are  to 
provide  documentation  and  training  for  the  engineering  user  and  methods  developer, 
an  analysis  of  System  change  requests  during  the  Validation  Phase,  and  an  anal- 
ysis of  the  effect  of  those  proposed  changes  related  to  helicopter  analysis  and 
mathematical  analysis.  Most  of  the  personnel  in  the  Technology  Analysis  and 
Design  Technical  Area  are  drawn  from  the  integrated  team  member  subcontrac- 
tor. No  coding  is  performed  by  personnel  of  the  Technology  Analysis  and  Design 
Technical  Area. 
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The  Software  Technical  Area  prepares  that  part  of  the  Type  B5  Development 
Specifications  associated  with  executive  and  support  software  (these  include  the 
Executive  Component  of  the  Operational  Complex  and  the  Support  Complex;  see 
Sections  2.3.2  and  2.4,  respectively).  For  those  CPCIs  that  have  been  allocated 
to  the  Development  Phase  Contractor,  this  technical  area  is  responsible  for  the 
following  activities: 

• Prepare  complete  Type  C5  Computer  Program  Product  Specifications 

• Code  all  software  in  conformance  with  the  approved  design  and  Project 
programming  standards 

• Perform  module  and  CPCI  testing  (Internal  Developer  Testing) 

The  Software  Technical  Area  is  also  responsible  for  maintenance  of  the  First 
Level  Release  and  all  associated  software  (i.  e. , non-engineering  user)  documen- 
tation. Because  of  this  maintenance  responsibility,  the  Software  Technical  Area 
will  produce  and  maintain  the  System  Maintenance  Manual. 
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The  Product  Assurance  Technical  Area  is  the  quality  assurance  agent  of  the  Tech- 
nical Director.  The  responsibilities  of  this  technical  area  are  to 

I 

• Conduct  integration  testing  (Preliminary  Qualification  Testing) 

• Conduct  acceptance  tests  (Formal  Qualification  Testing) 

• Conduct  functional  demonstration  of  the  System 

• Provide  quality  assurance  and  configuration  management  functions 

• Integrate,  and  provide  configuration  management  control  for,  the 
products  of  the  Technology  Analysis  and  Design  and  Software  Tech- 
nical Areas 

• Maintain  the  source,  object,  and  executable  decks  in  a Program 
Support  Library 

• Prepare  the  products  (e.g. , tapes)  for  the  First  and  Second  Level 
Releases 

• Install  and  qualify  the  First  and  Second  Level  Releases 

• Evaluate  System  performance 

• Prepare  the  integration  and  acceptance  test  plans  and  specifications 

• Prepare  the  integration  and  acceptance  Test  ’Analysis  Reports 

• Perform  an  independent  quality  assurance  review  of  all  technical 

documentation  items  (those  CDRL  items  that  are  not  associated  1 

with  planning,  progress,  costs,  and  reviews)  for  technical  content  , 

and  conformance  to  standards 

• Evaluate  source  code  for  conformance  to  Project  programming 
standards 

• Integrate  into  the  System  and  qualify  CPCIs  developed  by  CPCI  sub- 
contractors and  the  Government 

l 

f I 

238 


4 


• Provide  the  focal  point  for  System  maintenance 

• Provide  the  focal  point  for  communication  with  the  Government/ 
Industry  User  Community 

In  addition  to  these  three  organizations,  a small  technical  staff  reports  to  the 
Technical  Director,  providing  the  functions  of  system  engineering  and  data  base 
administration.  The  system  engineering  staff  function  provides  a focal  point  for 
hardware  requirements  considerations  and  for  the  allocation  of  System  functions 
to  hardware  or  software.  The  data  base  administration  function  provides  for  the 
integrity  of  the  Master  Data  Base. 

The  allocation  of  these  line  and  staff  functions  to  the  Development  Phase  Contrac- 
tor, the  integrated  team  member  subcontractor,  and  CPCI  subcontractors  is 
discussed  in  Section  5. 1.2.3. 

5. 1.2. 1 Project  Manager's  Responsibilities  and  Authorities 

The  success  of  the  development  of  the  Second  Generation  Comprehensive  Helicop- 
ter Analysis  System  will  depend  to  a great  extent  on  the  effectiveness  of  the 
Project  Manager.  Based  on  extensive  past  experience  with  similar  software  de- 
velopment efforts  (large,  multiuser,  transportable  systems  to  be  used  by  a 
large  user  community  over  a long  period  of  time),  CSC  has  found  that  the  Project 
Manager  must  be  completely  responsible  for  the  technical  and  financial  success 
of  the  Project.  His  objective  is  to  complete  the  Project  in  accordance  with  the 
contractual  specifications  and  within  the  budgetary  and  time  constraints  of  the  con- 
tractual agreement.  He  exercises  positive  management  controls  as  prescribed 
by  CSC's  policies  and  procedures  and  he  is  responsible  for  all  determinations 
regarding  cost,  schedule,  scope  of  work,  and  technical  approach.  Accordingly, 
he  has  the  responsibility  and  authority  for  planning,  organizing,  conducting, 
directing  and  controlling,  reviewing,  and  reporting  all  aspects  of  the  Project 
(1.  e. , technical,  schedule,  administrative,  and  cost)  from  inception  through 
successful  completion,  in  accordance  with  the  contract  scope  of  work. 


I 

y 

( 

y 

y 

f 

The  Project  Manager's  general  responsibilities  are  to  define  the  contractual 
effort;  assign  responsibilities;  and  plan,  schedule,  budget,  and  authorize  the 

i 

work.  He  compares  planned  and  actual  costs,  analyzes  variances,  incorporates 
changes,  and  develops  estimates  of  final  costs.  Other  responsibilities  are  to 
segregate,  review,  track,  control,  and  report  resource  utilization  to  both  CSC 
and  Government  management  and  anticipate  situations  that  affect  schedules  and 
resources  before-the-fact  and  provide  alternative  solutions.  He  is  also  respon- 
sible for  establishing  and  monitoring  all  subcontracts. 

To  fulfill  these  responsibilities,  the  Project  Manager 

• Ensures  the  quality  of  all  deliverable  items 

• Acts  as  the  single  point  of  contact  between  the  Government  and  CSC 

• Plans,  evaluates,  controls,  and  directs  the  schedule,  cost,  and 
technical  performance  of  the  Project 

• Provides  clear  statements  of  work  to  the  subcontractors 

• Monitors  subcontractor  work  to  ensure  performance,  schedule, 
and  cost  compliance 

• Develops,  issues,  maintains,  updates,  and  controls  all  work  . ^ 

schedules  and  plans 

• Reviews  and  evaluates  (on  a regular  basis)  technical,  cost,  and 
schedule  performance  against  plan 

• Monitors  performance  on  all  tasks  , 

• Controls  all  direct  charges  incurred  on  the  Project 

. 

• Discusses  problem  areas  with  the  Contracting  Officer's  Represents-  < 

tive  (Technical)  when  they  occur  and  provides  alternative  solutions 
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• Identifies,  describes,  and  establishes  channels  for  Project  commu- 
nications 

• Determines  the  need  for  and  defines  operating  procedures  peculiar 
to  the  Project's  requirements 

• Reports  Project  status  to  the  Government  in  accordance  with  the 
specified  contractual  reporting  requirements;  reports  internally 
to  management  of  CSC's  System  Sciences  Division 


• Utilizes,  through  the  Division's  support  organizations,  CSC  business 
management  and  data  processing  systems,  facilities,  and  services 
to  obtain  maximum  responsiveness  to  the  Project's  needs 

• Determines  the  functional  skill  requirements  and  selects  and 
manages  all  personnel  assigned  to  the  Project 

• Maintains  active  liaison  and  open  communication  links  with  the 
Government,  subcontractors,  and  the  Government/Industry  User 
Community  to  ensure  complete  visibility  of  Project  status  and  to 
ensure  CSC's  responsiveness  to  the  Government's  needs 

• Conducts  regularly  scheduled  Project  reviews  for  CSC  management 

• Meets  regularly  with  Government  personnel  to  review  status,  plans, 
and  approaches 

CSC  delegates  complete  authority  for  Project  management  and  control  to  the 
Project  Manager.  The  Project  Manager  is  authorized  to 


• Deal  directly  with  the  Government  for  all  technical  direction  and 
input  necessary  for  successful  technical  and  financial  performance 
of  contractual  requirements 

• Assign,  to  CSC  personnel  and  subcontractors,  responsibilities  for 
work  and  authorize  work  to  be  done  within  the  contractual  scope 
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• Incorporate  changes  and  develop  estimates  of  final  costs 
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• Grant  final  CSC  approval  on  all  Project  work 

• Control  assignments  of  CSC  personnel  to  the  Project 

• Authorize  and  approve  all  labor  and  other  direct  expenditures 
charged  to  the  contract 

5. 1.2.2  Technical  Director's  Responsibilities  and  Authorities 

The  Project  Manager  delegates  to  the  Technical  Director  all  the  necessary 
authority  to  fulfill  the  latter’s  primary  responsibility,  which  is  to  ensure  the 
high  quality  of  all  Project  source  code  and  technical  documentation.  In  addition, 
the  Project  Manager  delegates  to  the  Technical  Director  all  the  authorities  of 
the  Project  Manager  in  the  Project  Manager’s  absence.  The  Technical  Director 
is  the  immediate  supervisor  of  the  three  Technical  Area  Leaders  and  therefore 
has  the  necessary  authority  to  ensure  high-quality  deliverables. 

5. 1.2.3  Line  Organizations 

The  three  line  organizations  reporting  to  the  Technical  Director  employ  per- 
sonnel from  the  Development  Phase  Contractor  and  the  integrated  team  member 
subcontractor.  In  addition,  for  those  CPCIs  developed  by  the  Government  and 
CPCI  subcontractors,  it  is  convenient  to  consider  Government  personnel  and 
CPC  I subcontractor  personnel  as  belonging  to  the  Software  Technical  Area. 

The  following  is  a summary  of  the  work  performed  by  persons  of  the  different 
organizations  within  the  three  line  organizations: 

• Most  of  the  personnel  in  the  Technology  Analysis  and  Design  Tech- 
nical Area  are  affiliated  with  the  integrated  team  member  sub- 
contractor. 

• Personnel  in  the  Technology  Analysis  and  Design  Technical  Area 

act  as  consultants,  as  required,  to  personnel  in  the  Software  Technical 
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Area  in  the  module  and  CPCI  testing  of  the  software  of  the  Technology 
Component. 

• There  are  no  Government  personnel*  or  CPCI  subcontractor  per- 
sonnel in  the  Technology  Analysis  and  Design  Technical  Area. 

• The  majority  of  the  personnel  in  the  Software  Technical  Area  are 
affiliated  with  the  Development  Phase  Contractor.  At  least  one 
full-time  person  affiliated  with  the  integrated  team  member  sub- 
contractor aids  in  internal  developer  testing  at  the  module  and 
CPCI  levels.  The  Development  Phase  Contractor  personnel  in  the 
Software  Technical  Area  act  as  consultants  to  Government  and  CPCI 
subcontractor  personnel  in  the  same  technical  area  in  the  interpreta-  , 
tion  of  Project  standards.  (This  does  relieve  these  latter  personnel 
from  the  responsibility  of  knowledge  and  implementation  of  the  stand- 
ards.) 

• The  majority  of  the  personnel  in  the  Product  Assurance  Technical 
Area  are  affiliated  with  the  Development  Phase  Contractor.  However, 
a significant  contribution  from  integrated  team  member  subcontractor 
personnel  is  required  to  conduct  tests,  prepare  test  documentation, 
and  analyze  System  change  requests.  CSC  does  not  envision  any 
Government  personnel  or  CPCI  subcontractor  personnel  in  the  Prod- 
uct Assurance  Technical  Area. 

Table  4 explains  the  relationships  among  the  elements  of  the  Project  organiza- 
tion (Project  Manager,  Support  Services  Staff,  Technical  Director,  Technical 
Director's  Staff,  Technology  Analysis  and  Design  Technical  Area,  Software 
Technical  Area,  and  Product  Assurance  Technical  Area),  the  activities  they 
perform,  and  the  organizations  involved  and  the  extent  of  their  involvement. 


♦The  term  "Government  personnel"  is  used  in  this  section  to  mean  those  organi- 
zations who  are  producing  Government-furnished  CPCIs. 
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Table  4.  Relationships  Among  the  Organizations  involved  in  System 
Development  and  Maintenance  (1  of  2) 
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Each  activity  is  classified  as  end-item  oriented  (E)  or  non-end-item  oriented  (NE). 

The  responsibility  for  performing  an  activity  can  be  one  of  three  types:  delegated 
(D),  support  (S),  or  advisory  (A).  An  organization  is  delegated  an  activity  without 
any  support  or  advice  from  another  organization  when  the  nature  of  the  activity 
warrants  it.  It  is  CSC's  goal  to  delegate  as  many  activities  as  possible  to  de- 
crease the  probability  of  communication  gaps  and  to  decrease  travel  and  per  diem 
costs.  To  help  meet  this  goal,  CSC  strives  to  make  an  activity  end-item  oriented 
whenever  possible.  When  an  activity  cannot  be  delegated  completely  to  one  or- 
ganization, a principal  (P)  organization  will  be  delegated  primary  responsibility, 
if  appropriate  for  the  activity,  and  other  organizations  will  be  delegated  secondary/ 
support  (S)  responsibility  or  tertiary /advisory  (A)  responsibility. 

5.2  MANAGEMENT  PLANS 

The  management  plans  in  this  section  consist  of  the  Development  Control  Plan 
(Section  5.2. 1);  the  Work  Management  Plan  (Section  5.2.2)-{  the  Communication 
Plan  (Section  5.2.3);  the  Internal  Review  and  Reporting  Plan  (Section  5.2.4);  the 
Configuration  Management  Plan  (Section  5.2.5);  and  the  Documentation  Manage- 
ment Plan  (Section  5.2.  6).  These  plans  are  based  on  similarly  titled  plans  in  the 
Baseline  Development  Plan;  the  plans  presented  here  are  for  the  most  part  sum- 
marized from  those  in  the  Baseline  Development  Plan. 

5.2.1  Development  Control  Plan 

f - L 

Effective,  positive  control  of  the  development  of  a large,  complex  software  sys- 

\ 

tern  is  critical  to  its  integrity  and  to  its  acceptance  by  its  intended  users.  Control 
of  the  development  of  the  Second  Generation  Comprehensive  Helicopter  Analysis 
System  is  particularly  critical  because  the  System  is  projected  to  be  used  for 
15  years  after  the  start  of  the  Development  Phase  and  because  many  of  the  CPCIs 
will  be  developed  by  different  organizations. 
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To  help  ensure  that  the  objectives  for  the  System  are  met  and  the  Government's 

premises  for  the  Development  Phase  are  followed,  the  following  elements  for  i 

controlling  development  are  recommended: 

1.  The  Government  should  require  the  Development  Phase  Contractor  to 
prepare  a System  Development  Plan  for  Government  approval  2 months  after 
award  of  the  Development  Phase  contract.  CSC  envisions  that  the  System  Devel- 
opment Plan  evolves  from  the  Baseline  Development  Plan;  defines  the  responsi- 
bilities of  the  various  organizations  involved  in  development;  serves  as  an 
up-to-date  baseline  source  of  information  about  all  technical  and  management 
aspects  of  the  System's  development;  and  is  available  to  all  concerned  organiza- 
tions. In  addition  to  the  up-to-date  information  presented  in  the  Baseline  Devel- 
opment Plan,  the  System  Development  Plan  contains:  a detailed  technical  approach 
that  is  the  contractor's  work  breakdown  structure  response  to  the  Development 
Phase  contract's  Statement  of  Work  (see  paragraph  5 below);  a Source  Selection 
Plan  for  governing  the  selections  of  CPCI  subcontractors;  a PERT  chart  for  the 
entire  Development  Phase;  a Project  Milestone  Schedule;  a Project  glossary;  an 
Organizational  Interface  Plan;  and  a summary  of  the  initial  System  design. 

2.  The  Government  should  require  the  Development  Phase  Contractor  to 

P 

review,  for  consistency,  accuracy,  and  completeness,  the  two  sets  of  standards 

to  be  provided  by  the  Government  for  the  System:  Programming  Standards  for  the 

35 

Second  Generation  Comprehensive  Helicopter  Analysis  System  and  Nomenclature 

36 

of  the  Second  Generation  Comprehensive  Helicopter  Analysis  System.  CSC  ' 

suggests  that  the  results  of  this  review,  in  the  form  of  recommended  revisions 
to  each  standards  document  (l.  e. , the  nomenclature  document  and  the  program- 
ming standards  document),  be  identified  as  a CDRL  data  item  to  be  submitted  for 
Government  approval  2 months  after  the  award  of  the  Development  Phase  contract. 

The  approved  recommended  revisions  should  then  be  used  as  the  basis  for  estab- 
lishing the  baselines  of  each  standards  document.  The  baseline  standards  docu- 
ments can  then  serve  as  the  up-to-date  baseline  source  of  nomenclature  and 
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programming  standards  for  all  organizations  involved  in  the  development  of  the 
System. 

3.  The  Government  should  require  quarterly  or  triannual  review  meetings 
with  the  Government,  the  Government/industry  Working  Group,  the  Technical 
Advisory  Group,  the  Development  Phase  Contractor,  the  integrated  team  member 
subcontractor,  CPCI  subcontractors,  and  organizations  providing  Government- 
furnished  CPCIs.  These  meetings  will  provide  a forum  for  exchanging  ideas  and 
information  and  for  solving  problems  between  organizations.  The  format  of  these 
meetings  would  be  described  in  the  Organizational  Interface  Plan  of  the  System 
Development  Plan. 

4.  Methods  should  be  recommended  for  providing  regular  and  rapid  com- 
munication among  all  organizations  involved  in  development.  Possible  methods 
include  a monthly  newsletter  supplemented  by  bulletins  as  required  and  a computer 
information  network. 

5.  The  System  Development  Plan  should  contain  the  detailed  technical 
approach  to  be  followed  by  the  Development  Phase  Contractor,  subcontractors, 
and  the  Government  during  the  Development  Phase.  The  order  of  presentation 
of  the  detailed  technical  approach  is  hierarchical  and  is  keyed  to  the  work  break- 
down structure  (WBS),  an  integral  part  of  the  response  to  the  Statement  of  Work 
in  the  Request  for  Quotation  for  the  Development  Phase.  The  detailed  technical 
approach  is  presented  at  four  successively  more  refined  levels  of  detail,  each 
level  of  detail  corresponding  to  a level  of  the  WBS: 

• Project  Level — Level  I of  the  WBS 

• Task  Level — Level  II  of  the  WBS 

• Subtask  or  Product  Level — Level  HI  of  Ihe  WBS 

• Activity  or  Subproduct  Level — Level  IV  of  the  WBS 
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At  the  Project  level,  the  objectives  of  the  Project  are  presented,  the  tasks  com- 
prising the  Project  are  named,  and  a brief  statement  of  the  objective  of  each  task 
is  provided. 

At  the  task  level,  the  scope  and  objectives  of  each  task  and  the  general  approach 
to  be  followed  in  meeting  the  objectives  of  the  task  are  presented.  The  scope  is 
a brief  summary  of  the  task,  the  objectives  are  presented  in  terms  of  the  end 
items  (products)  resulting  from  a successful  conclusion  to  the  task,  and  the  gen- 
eral approach  discussion  emphasizes  (1)  (he  interrelationships  of  the  task  to  other 
tasks  and  dependencies  of  the  task  on  other  tasks  and  (2)  interrelationships  and 
dependencies  among  the  subtasks  of  the  task. 

At  the  subtask  or  product  level,  the  inputs,  activities,  and  product  of  each  subtask 
are  summarized.  The  interrelationships  with,  and  dependencies  on,  other  sub- 
tasks are  discussed.  The  schedule  and  a summary  of  the  resources  budgeted  for 
the  subtask  are  presented.  The  standard  that  will  be  used  to  measure  the  quality 
of  the  product  is  referenced.  The  plan  for  integration  of  the  subproducts  is  pre- 
sented. This  plan  will  emphasize  (1)  the  definition  of  the  interfaces  among  the 
organizations  (e.  g. , subcontractors)  responsible  for  the  subproducts  of  the  pro- 
duct and  (2)  the  Interfaces  among  the  subproducts. 

At  the  activity  or  subproduct  level,  the  inputs,  work  elements,  and  results  of 
each  activity  are  presented.  The  schedule  and  resources  budgeted  for  the  activity 
are  also  given. 

In  addition  to  the  narrative  described  above,  the  detailed  technical  approach  is 
summarized  in  a Project  Milestone  Schedule  and  a PERT  chart. 

5.2.2  Work  Management  Plan 

The  Work  Management  Plan,  presented  in  the  Baseline  Development  Plan  and 
summarized  here,  gives  CSC's  approach  to  managing  the  work  in  the  Development 
Phase.  The  plan  presents  CSC's  approach  to  (1)  defining  the  work  and  assigning 
responsibilities  to  perform  the  work;  (2)  planning,  scheduling,  budgeting,  and 
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authorizing  the  work;  (3)  controlling  costs;  (4)  incorporating  changes  and  devel- 
oping final  costs;  (5)  segregating,  reviewing,  tracking,  controlling,  and  reporting 
resource  utilization;  (6)  anticipating  situations  that  affect  schedules  and  resources; 
and  (7)  managing  subcontractors.  The  paragraphs  below  summarize  the  main 
points  of  the  Work  Management  Plan. 

5.2.2. 1 Defining  the  Contractual  Effort  and  Assigning  Responsibilities 

CSC's  approach  to  defining  the  contractual  effort  of  the  Development  Phase  and 
assigning  responsibilities  has  been  and  will  be  a continuing  effort.  This  approach 
has  been  applied  during  the  Predesign  Phase  and  will  be  applied  during  the  pre- 
proposal phase,  and  the  proposal  phase  and  will  be  finalized  in  the  first  2 months 
of  the  Development  Phase  to  arrive  at  a Detailed  Technical  Approach.  The  De- 
tailed Technical  Approach  will  include  a detailed  definition  of  the  work  in  the  form 
of  a Work  Breakdown  Structure  (WBS),  and  an  accompanying  narrative  assignment 
of  work,  planned  schedules,  and  budgets.  This  has  already  been  discussed  in 
paragraph  5 of  Section  5.2. 1.  Immediately  following  award  of  the  Development 
Phase  contract,  CSC  proposes  to  meet  with  the  Government  to  review  this  ap- 
proach and  identify  aspects  needing  modification  based  on  the  Government's  eval- 
uation. A minor  planning  adjustment  activity  is  anticipated  to  result  from  this 
meeting;  other  than  this  adjustment,  CSC's  management  approach  for  defining 
the  Development  Phase  effort  and  assigning  responsibilities  will  have  been  im- 
plemented. The  Detailed  Technical  Approach  is  documented  in  the  System  De- 
velopment Plan. 

Responsibilities  will  be  assigned  by  CSC  to  Itself,  the  integrated  team  member 
subcontractor,  CPCI  subcontractors,  and  the  Government,  based  on  the  type  of 
work  to  be  done.  All  such  assignment  of  responsibilities  will  of  course  be  subject 
to  Government  approval.  A discussion  of  what  types  of  work  CSC  plans  to  assign  • 

to  itself,  the  integrated  team  member  subcontractor,  its  CPCI  subcontractors, 
and  the  Government  is  provided  in  Section  5. 1 of  this  report. 
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5. 2. 2. 2 Planning,  Scheduling,  Budgeting  and  Authorizing  the  Work 

A basic  part  of  the  management  process  is  the  thorough  planning  of  all  elements  i 

of  work.  This  involves  the  evolution  of  detailed  development  schedules  for  all 

tasks  and  subtasks;  detailed  budgets  for  all  human  resources  and  for  subcontract 

and  other  direct  cost  items;  and  schedules  for  the  delivery  of  all  specifications 

and  documentation  to  be  produced.  This  section  describes  the  development  of  the 

plans,  schedules,  and  budgets  that  are  the  products  of  the  work-planning  activity. 

• Work  planning  for  the  Development  Phase  began  with  pre-proposal  work  for  the 

Predesign  Phase;  has  continued  during  the  Predesign  Phase  study  efforts;  will 
become  more  detailed  during  the  proposal  for  the  Development  Phase;  and  will 
culminate  with  the  System  Development  Plan  approved  by  the  Government  2 months 
after  Development  Phase  contract  award. 

The  first  step  in  the  effective  control  of  schedules  and  costs  is  the  planning  activ- 
ity, the  results  of  which  are  incorporated  in  the  System  Development  Plan  and 
which  provide  the  framework  and  measurement  basis  for  monitoring  progress. 

The  initial  part  of  the  planning  process  is  work  definition,  discussed  in  Sec- 
tion 5.2.2. 1.  The  next  activity  involves  specifying  initiation  and  completion  dates 
that  are  consistent  with  constraints  imposed  by  the  interdependencies  among  the 
subtasks  and  various  other  factors.  These  include  the  availability  of  required 
input  data  and  requirements  from  the  Government  and  industry  interfaces,  delivery 

If 

dates  specified  in  the  contract,  and  efficient  use  of  resources. 

I * P 

The  first  step  in  this  process  is  to  estimate  the  amount  of  time  required  to  ' 

» complete  each  subtask.  Generally,  this  time  is  a function  of  the  magnitude  of 

the  work  required,  the  human  resources  assigned,  the  skill  level  and  related 
experience  of  the  assigned  personnel,  and  the  usefulness  of  computer  time. 

The  initial  estimate  is  based  on  those  human  resource  and  skill  levels  judged 
to  be  most  cost  effective.  The  subtasks  are  then  arranged  in  a schedule  that 
accounts  for  interdependencies,  specified  dates  for  reviews,  and  use  of  parallel 
activities  to  maintain  continuity  of  personnel  and  uniformity  of  workloads. 
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The  initial  schedule  is  then  analyzed  and  revised  as  necessary  to  ensure  that  it 
meets  the  requirements.  The  resulting  planned  schedule  is  called  the  Project 

i 

Milestone  Schedule.  After  Development  Phase  initiation,  the  Project  Milestone 
Schedule  will  be  reexamined  to  take  into  account  any  changes  resulting  from 
initial  discussion  with  the  Government.  This  schedule  will  be  a principal  man- 
agement control  tool  throughout  the  Development  Phase.  As  the  Development 
Phase  evolves,  the  schedule  will  be  reviewed  frequently  (at  least  weekly).  It 
will  be  revised  as  necessary  to  include  deviations  from  the  planned  schedule 
and  more  detailed  schedule  information  when  appropriate.  Thus,  planning  and 
scheduling  will  be  continuing  activities  throughout  the  Development  Phase. 

Plans  must  be  continually  reviewed  and  revised  to  be  responsive  to  the  current 
situation  and  latest  information  available.  These  plans  and  the  necessary  re- 
visions to  them  will  be  continually  available  to  the  Government  to  review, 
analyze,  and  provide  feedback  and  direction. 

When  the  schedule  development  process  is  complete,  the  associated  human 
resource  requirements  are  assembled  for  all  subtasks.  Computer  time,  travel, 
and  other  costs  are  determined,  and  estimates  of  support- services  require- 
ments as  well  as  the  time  for  project  management  and  review  activities  are 
determined.  This  Information  is  then  developed  Into  a planned  budget  which  is 
the  principal  control  tool  for  monitoring  financial  performance. 

Work  authorization  is  the  responsibility  of  the  Project  Manager.  After  com- 
pletion  of  the  work  definition  activity,  which  defines  the  tasks  and  subtasks  to 
the  lowest  practical  level,  and  assignment  of  responsibilities  for  work  as  dis- 

* 

cussed  in  the  previous  section,  the  Project  Manager  authorizes  commencement 
of  subtasks  in  accordance  with  the  Project  Milestone  Schedule.  Deviations  from 
the  schedule  are  brought  to  the  attention  of  the  Project  Manager  by  the  Internal 
reporting  system  described  in  Section  5.2.4. 
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Subcontractor  work  authorization  Is  also  the  responsibility  of  the  Project  Manager, 
who  reviews  and  approves  each  subcontractor  statement  of  work.  The  subcon- 
tractor will  be  authorized  to  proceed  after  the  subcontract  has  been  accepted  and 
signed  by  both  parties  and  approved  by  the  Government. 

5. 2. 2. 3 Controlling  Costs 

For  effective  monitoring,  analysis,  and  control  of  costs  and  other  resource  ex- 
penditures, the  Project  Manager  must  have  accurate  and  up-to-date  information. 
CSC's  accounting  system  is  designed  to  provide  the  needed  data.  This  section 
describes  how  costs  are  controlled  by  use  of  cost  and  manpower  information  pro- 
vided to  the  Project  Manager. 

The  information  provided  to  the  Project  Manager  must  convey  both  the  amount 
expended  on  the  total  project  in  each  of  the  cost  accrual  categories  and  the  dis- 
tribution of  the  expenditures  among  the  tasks  composing  the  project.  CSC's 
time  and  cost  accounting  procedures  provide  the  Project  Manager  with  full  con- 
trol over  resource  expenditure  and  great  flexibility  in  accumulating  cost  data 
in  a variety  of  categories  specifically  tailored  to  the  Project.  Data  are  entered 
into  CSC's  automated  accounting  system,  where  they  become  part  of  a common 
data  base  from  which  expenditure  reports  for  the  Project  Manager,  CSC  top 
management,  and  the  Government  are  generated.  All  parties  are  thus  ensured 
of  consistent  resource  expenditure  data. 

5. 2. 2. 4 Incorporating  Changes  and  Developing  Final  Costs 

Effective  control  and  monitoring  procedures  allow  accurate  assessment  of  changes 
in  requirements  or  specifications  and  determination  of  the  effects  of  such  changes 
on  final  costs  and  schedules.  In  a program  such  as  the  Second  Generation  Com- 
prehensive Helicopter  Analysis  System,  controlling  changes  that  affect  the  final 
outcome  is  an  extremely  important  function  of  Project  management.  CSC  will 
evaluate  changes  during  the  Development  Phase  based  on  the  assumption  that  Sec- 
tion L,  Paragraph  62,  of  CSC's  Predesign  Phase  contract  will  also  appear  in  the 
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Development  Phase  contract,  and  that  the  Configuration  Management  Plan  will 
provide  the  policy  for  proposing  and  implementing  changes.  The  reader  is  refer- 

l 

red  to  the  Baseline  Development  Plan  for  more  details. 

5. 2. 2. 5 Segregating,  Reviewing,  Tracking,  Controlling,  and  Reporting  Resource 
Utilization 

CSC's  accounting  system  allows  detailed  segregation,  tracking,  and  reporting  of 
costs  and  hours  within  predetermined  categories  and  provides  weekly  and  monthly 
reports  of  resource  utilization  for  the  Project  Manager's  review.  , 

The  data  provided  on  the  weekly  Project  Manager's  Report  and  the  weekly  Labor 
Distribution  Report  is  as  follows: 

• Expenditure  of  hours  by  named  individuals 

• Total  hours  expended  for  the  week  and  total  funds  expended  for  the 
week  by  category  (direct  labor,  overhead,  etc. ) 

• Cumulative  hours  and  funds  expended  to  date 

• Budgeted  hours  and  funds 

• Percentage  of  total  hours  and  funds  expended 

• Variance  from  budgets  ' ' 

The  percentage  of  the  work  actually  completed,  by  work  element,  is  estimated 
by  the  lead  technical  personnel  of  the  particular  tasks  or  subtasks  and  is  re- 
ported on  the  Project  Milestone  Schedule  maintained  by  the  Project  Manager.  1 

General  CSC  management  also  has  responsibility  for  tracking  and  controlling  * 

the  Development  Phase.  To  support  fulfillment  of  this  responsibility,  each 
Project  Manager  is  required  to  complete  a Monthly  Project  Status  Report 
(MPSR)  to  Division  and  Corporate  management.  This  report  contains  a brief 
summary  of  task  status  with  respect  to  performance  level,  conformance  to 
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schedule,  and  resource  expenditures.  Problems  in  any  of  these  areas  are  high- 
lighted and  discussed  to  alert  management  to  the  possible  need  for  special  atten- 
tion. The  MPSR  also  includes  an  up-to-date  summary  financial  chart  depicting 
budgeted  expenditures  versus  time  and  actual  expenditures  to  date  and  a current 
Project  Milestone  Schedule  for  the  Project  indicating  actual-versus-planned 
» progress. 

5. 2. 2. 6 Anticipating  Situations  That  Affect  Schedules  and  Resources 

* No  one  wants  to  be  surprised  by  "sudden"  slips  in  schedule  or  increases  in  costs. 

Completion  dates  of  major  milestones  do  not  slip  several  weeks  during  a single 
day;  nor  do  costs,  in  resources  or  dollars,  escalate  overnight.  If  they  appear  to 
do  so,  it  is  almost  totally  due  to  a failure  in  management  control  and  to  a lack  of 
visibility  or  communication.  The  majority  of  serious  problems,  delays,  and  cost 
increases  can  be  completely  avoided  if  effective  control  techniques  are  used  to 
Identify  problems  early  enough  to  be  remedied  with  corrective  action. 

The  basic  structure  of  the  control  process  for  schedules,  costs,  and  other  re- 
source items  which  CSC  currently  uses  and  plans  to  use  for  the  Development  Phase 
consists  of  the  following: 

• Planning — Thorough  planning  of  all  elements  of  work,  including 

detailed  development  schedules  for  all  significant  work  elements, 
detailed  and  realistic  budgets  for  all  human  resource  and  cost  items, 
and  schedules  for  all  specifications  and  documentation.  The  key  to 
successful  planning,  monitoring,  and  control  is  the  breakdown  of 
» the  work  into  discrete  work  elements  whose  completion  can  be  ob- 

jectively evaluated. 

e Monitoring  and  reporting— Continual  tracking  of  performance, 

progress,  and  costs  and  comparison  of  these  items  with  the  origi- 
nal plans  and  budgets;  communication  of  the  results  of  this  moni- 
toring both  internally  and  to  the  Government  through  written  and 
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verbal  reporting  and  informal  communication;  and  projection  of 
possible  problem  areas  and  development  of  contingency  plans. 

• Corrective  action — Quick  response  to  identified  problem  areas, 
schedule  variances,  or  deviations  from  budget  through  the  use  of 
management  action,  alternative  solutions,  or  revised  plans. 

To  be  effective,  the  planning  function  must  result  in  a detailed  Project  Milestone 
Schedule  based  on  activities  characterized  by  meaningful  measures  of  progress 
and  completion.  For  the  Development  Phase,  these  measures  are  linked  to  the 
documentation  to  be  delivered,  the  reviews  to  be  conducted,  the  source  code 
to  be  produced,  the  tests  to  be  conducted,  the  CPCIs  to  be  developed,  and  the 
software  to  be  released  to  the  helicopter  manufacturers  and  to  the  Government 
agencies.  The  monitoring  and  reporting  functions  are  designed  to  collect  and 
present  information  to  management,  permitting  meaningful  assessment  of 
progress  against  plan.  Finally,  the  information  and  planning  must  facilitate 
management's  ability  to  evaluate  the  effect  of  alternative  approaches  aimed  to 
correct  deviations  between  plan  and  progress.  The  responsibility  for  collecting 
and  evaluating  this  information  rests  with  the  Project  Manager,  as  does  the 
authority  for  specifying  that  it  be  provided.  The  Project  Manager  will  be 
assisted  in  this  function  by  all  members  of  the  technical  staff. 

The  progress-monitoring  activities  to  be  used  include  weekly  progress  reports; 
regular  staff  meetings;  internal  design  reviews;  documentation  reviews;  test 
material  reviews;  source  code  reviews;  and  informal,  person-to-person  reviews. 
These  activities  are  described  in  Section  5.2.4. 

If  a serious  existing  or  potential  problem  is  Identified  either  by  Project  per- 
sonnel or  through  any  of  the  previously  mentioned  progress-monitoring  activities, 
the  Project  Manager  may  call  for  a technical  audit.  To  conduct  this  audit,  an 
ad  hoc  team  of  highly  qualified  senior  technical  staff  members  will  be  formed 
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by  the  Project  Manager.  The  participation  of  specialized  experts  from  through- 
out the  Division  and,  if  necessary,  other  divisions  of  the  Corporation,  can  be 
requested.  This  team  will  review  the  problem  in  detail,  working  closely  with 
Project  personnel;  identify  alternative  solution  approaches;  and  prepare  a 
recommended  course  of  action.  The  result  of  this  audit  will  be  provided  imme- 
diately to  the  Project  Manager.  Responsibility  for  implementing  the  solution 
rests  with  the  Project  Manager. 

Another  key  element  of  successfully  anticipating  situations  that  affect  schedules 
and  resources  is  careful,  formalized  control  of  changes  to  the  System  require- 
ments. Experience  demonstrates  that  uncontrolled  modification  of  requirements, 
if  permitted,  leads  rapidly  to  an  uncontrolled  state  of  escalating  costs,  degraded 
system  integrity  and  reliability,  and  unknown  status.  The  procedures  embodied 
in  the  Configuration  Management  Plan  in  the  System  Development  Plan  will  be  ap- 
plied to  ensure  that  changes  in  the  Development  Phase  are  effectively  controlled 
during  System  development. 

5 . 2 . 2 . 7 Managing  Subcontractors 

Success  in  any  contract  relationship  is  achieved  through  an  explicit  statement 
of  work  to  be  performed  by  the  prime  contractor;  thorough  understanding  of 
the  work  to  be  performed  by  the  subcontractor;  periodic  reports  of  progress 
measured  against  meaningful  milestones;  and  frequent,  effective  formal  and  in- 
formal communications  to  continually  refine  and  feed  back  mutual  understanding. 

The  relationships  between  CSC  and  the  integrated  team  member  subcontractor  and 
the  CPCI  subcontractors,  will  be  governed  by  the  work-definition  and  work- 
planning  principles  given  in  Section  5. 2. 2. 7. 1 and  the  work-monitoring  principles 
in  Section  5. 2. 2. 7. 2.  These  principles  will  be  expanded  into  plans  prior  to  the 
start  of  the  Development  Phase. 
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5. 2. 2. 7. 1 Work-Definition  and  Work- Planning  Principles 


Defining  and  planning  the  work  to  be  done  by  subcontractors  are  guided  by  the 
principles  given  below. 

• The  Government’s  Statement  of  Work  in  the  prime  contract  is  mapped 
as  directly  as  possible  into  the  Statement  of  Work  for  the  subcontrac- 
tor. 

• As  many  of  the  work  elements  as  possible  are  made  end-item  (deliv- 
erable) oriented  to  permit  effective  monitoring  and  to  minimize  travel 
and  per  diem  costs. 

• Subcontractor  personnel  work  on  site  with  CSC  personnel  during  cru- 
cial stages  of  work  planning  and  software  integration  when  face-to- 
face  communication  is  necessary. 

• Deliverables  are  specified  in  detail  to  permit  effective  monitoring  of 
progress  versus  plan. 

• Deliveries  of  subcontract  data  items  are  provided  incrementally. 

• The  provisions  of  the  prime  contract  are  passed  down  to  each  sub- 
contract to  the  maximum  extent  applicable. 

• A detailed  performance  plan,  which  will  contain  both  technical  and 
management  subplans,  is  required  of  each  subcontractor. 

• Subcontractor  personnel  participate  fully  with  CSC  personnel  during 
formal  reviews  with  the  Government  and  during  meetings  with  the 
Government/industry  Working  Group  and  the  Technical  Advisory 
Group. 

• Procurements  are  competitive  to  the  greatest  extent  possible. 
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5.  2. 2.  7. 2 Work-Monitoring  Principles 

Formal  written  Monthly  Letter  Progress  Reports  and  Monthly  Cost  and  Perform- 

■ 

ance  Reports  are  required  from  all  subcontractors.  These  reports  plus  review 
and  approval  or  disapproval  of  contract  deliverables  establish  one  level  of  mon- 
itoring of  the  subcontractor  by  CSC.  Moreover,  because  communication  is  essen- 
tial to  arrive  at  a satisfactory  end-product,  each  subcontract  is  monitored  by 
the  Project  Manager,  who  will  communicate  informally  with  the  subcontractor's 
Project  Manager  on  a regularly  scheduled,  weekly  basis  to  determine  the  actual 
progress  and  to  ensure  that  all  work  is  proceeding  according  to  plan.  Problems 
are  addressed  immediately,  and  alternative  solutions  discussed.  In  addition  to 
the  regular  weekly  status  telephone  calls,  frequent,  usually  daily,  conversation 
takes  place  between  CSC  and  subcontractor  personnel,  including  conference-type 
telephone  calls  when  required.  In  addition,  to  ensure  effective  communication 
and  control,  the  CSC  Project  Manager  makes  personal  visits  to  subcontractor 
facilities  at  least  once  every  2 months  when  all  work  is  being  performed  exclu- 
sively at  the  subcontractor's  facility. 

5.2.3  Communication  Plan 

The  Communication  Plan  describes  how  the  Development  Phase  Contractor  will 
communicate  with  the  Government  and  its  subcontractors.  A professional,  dis- 
ciplined approach  for  communicating  and  reporting  all  technical  activities  is 
prerequisite  for  project  success.  Accordingly,  CSC  plans  to  use  formal  technical 

' W 

communication  for  the  transmission  of  planned  activities,  status  and  progress 
reports,  and  problems.  This  plan  is  based  on  the  assumption  that  the  CDRL  will 
(and  should)  contain  the  same  media  for  communication  between  CSC  and  the  Gov- 
ernment during  the  Development  Phase  as  during  the  Predesign  Phase.  The 
Contract  Performance  Plan,  monthly  letter  progress  reports,  monthly  cost  and 
performance  reports,  progress/status  meeting  reports,  agendas  and  minutes  of 
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design  reviews,  and  interim  technical  reports  are  all  vehicles  for  CSC's  technical 
and  financial  communication  with  the  Government. 

Section  5. 2. 3.1  describes  CSC's  proposed  approach  for  formally  communicating 
and  reporting  all  technical  and  financial  information  between  the  Government  and 
CSC,  and  between  CSC  and  its  subcontractors.  Section  5. 2. 3. 2 describes  an 

7 

approach  for  establishing  a convenient  but  controllable  mechanism  for  informal 
technical  communication  between  CSC  and  its  subcontractors. 

5. 2. 3.1  Formal  Communication 

The  Contract  Performance  Plan  presents  the  Development  Phase  Contractor's 
approach  to  fulfilling  all  contract  requirements.  This  Contract  Performance  Plan 
is  a revised  version  of  the  plan  submitted  with  the  proposal  for  the  Development 
Phase.  Revisions  are  based  on  negotiations  and  Government  feedback.  As  work 
proceeds  on  the  development  of  the  System,  the  Development  Phase  Contractor 
maintains  regular  communication  with  the  Government  to  ensure  that  potential 
problems  are  dealt  with  as  they  arise.  The  reporting  structure  should,  as  a 
minimum,  consist  of  the  following: 

• Letter  Progress  Reports.  These  monthly  reports  are  the  principal 
formal  vehicle  for  reporting  status,  progress,  problems,  and  planned  activity  to 
the  Government.  The  Letter  Progress  Report  contains  brief  statements  on  the 
status  of  the  Project  and  provides  a comparison  of  actual  progress  with  the  planned 
progress  of  the  Contract  Performance  Plan.  It  discusses  the  schedule  status  of 
each  subtask  that  was  scheduled  to  begin,  end,  or  continue  in  the  reporting  period. 

An  assessment  of  the  effect  of  existing  problems  on  task  performance  is  given.  * 

Specific  plans  for  work  scheduled  for  the  next  2-month  period  and  reports  of  meet- 
ings with  the  Government  and  industry,  and  their  results,  are  provided. 

• Monthly  Cost  and  Performance  Reports.  These  reports  provide 
detailed  information  on  expenditures  of  hours  and  funds.  The  hours  expended 
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for  each  work  element  (e.g. , task,  subtask)  are  compared  with  the  budgeted 

hours,  and  a Judgement  is  made  as  to  the  adequacy  of  the  remaining  hours  for  i 

completing  the  effort.  Information  is  also  provided  about  the  funds  expended 

for  each  work  element,  a comparison  with  the  budgeted  amount  is  reported, 

and  a judgement  is  made  as  to  the  adequacy  of  funds  for  completion.  In  addition, 

the  percentage  of  work  completed  is  presented  for  each  work  element  with  an 

estimate  of  the  cumulative  percentage  of  total  work  completed  to  date. 

• Progress/Status  Meetings.  CSC  recommends  regular  meetings  every 
month  with  the  Government  at  Fort  Eustls.  This  type  of  technical  interchange  has 
proven  to  be  an  invaluable  method  for  reviewing  progress  and  discussing  areas  of 
concern.  Such  meetings  will  afford  the  Government  an  opportunity  to  raise  ques- 
tions and  receive  whatever  detailed  information  is  required  for  all  aspects  of  the 
ongoing  activities.  Following  each  meeting,  the  contractor  will,  in  accordance 
with  the  CDRL,  prepare  minutes  of  the  meeting  to  document  the  discussion.  Rec- 
ommendations made  by  CSC  or  the  Government  will  be  listed,  and  action  items 
will  be  noted  along  with  the  due  dates. 

• Reports  From  Subcontractors.  The  prime  contractor  will  be  the  sole 
reporter  to  the  Government.  Letter  progress  reports  and  cost  and  performance 
reports  from  subcontractors  are  incorporated  with  internal  information  and  in- 
cluded in  the  monthly  reports  to  the  Government.  (This  is  a corollary  to  the 
principle  stated  in  Section  5. 2. 2. 7. 1 that  provisions  in  the  prime  contract  will  be 
"passed  down"  to  each  subcontract. ) Subcontractors  provide  a monthly  progress 
report  summarizing  technical  activities  for  the  month  and  Identifying  any  possible 
problem  areas.  Subcontractors  also  provide  Monthly  Cost  and  Performance  Re- 
ports. Subcontracts  will  stipulate  that  these  reports  be  consistent  with  the  format 
of  the  prime  contractor's  report  to  the  Government. 

• Technical  Reports.  Technical  reports  include  all  the  deliverable  tech- 
nical documents  defined  in  the  CURL  that  are  not  categorized  as  status  reports, 
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progress  reports,  or  meeting  minutes.  Examples  of  these  technical  documents 
include  Type  B5  Development  Specifications,  Type  C5  Product  Specifications,  the 
Data  Base  Specification,  the  Test  and  Implementation  Plan,  the  Test  Analysis 
Report,  the  User's  Manual,  and  the  System  Maintenance  Manual.  The  Develop- 
ment Phase  Contractor  is  responsible  for  the  format,  content,  and  quality  of  each 
document  whether  the  document  is  prepared  by  the  integrated  team  member  sub- 
contractor, or  by  the  CPCI  subcontractor. 

5. 2. 3. 2 Informal  Communication 

All  managers  recognize  the  importance  of  informal  communication  in  meeting 
objectives  and  use  informal  communication  to  good  advantage.  Internal  and  ex- 
ternal organization  lines,  responsibilities,  lines  of  authority,  and  lines  of  com- 
munication between  the  Development  Phase  Contractor,  its  subcontractors,  the 
Government,  the  Government/Industry  Working  Group,  and  the  Technical  Advisory 
Group  have  been  discussed  in  Section  5. 1.  Informal  communication  exists  for  the 
purpose  of  coordination,  advice,  and  support.  Informal  communication  with 
Government/Industry  Working  Group  members  and  Technical  Advisory  Group 
members  occurs  at  the  joint  meetings  proposed  as  part  of  the  Development  Con- 
trol Plan  discussed  in  Section  5.2. 1.  Informal  communication  among  CSC  and 
subcontractor  personnel  consists  of  the  following; 

• Trips  to  CSC's  facility  by  subcontractor  personnel  and  to  subcon- 
tractors' facilities  by  CSC  personnel 

• Meetings  to  review  work  status 

• Face-to-face  contact  during  the  workday 

• Telephone  conversations 

• Informal  memoranda  regarding  recommendations,  technical  data, 
guidance,  information,  etc. 
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• Informal  exchange  of  preliminary  versions  or  parts  of  documents 
(usually  to  speed  information  flow  and  later  formalized  for  record 
purposes) 

A straightforward,  proven  mechanism  for  controlling  informal  written 
communication — a set  of  numbered  Project  memoranda — is  planned.  These  pro- 
vide the  means  to  quickly  document  and  transmit  technical  information  that  will 
be  useful  to  all  Project  personnel,  independent  of  organizational  affiliation,  and 
also  promote  communication  of  technical  matters  among  Project  personnel.  The 
memoranda  are  easily  referenced,  and  a file  is  maintained.  For  future  reference 
or  formalization,  other  memoranda  are  kept  of  significant  telephone  conversations, 
document  exchanges,  visits,  and  meetings. 

5.2.4  Internal  Review  and  Reporting  Plan 

Because  of  the  complexity  of  the  System  and  the  large  number  of  organizations  in- 
volved, effective  review  and  reporting  procedures  are  important  to  overall  Project 
success.  Based  on  an  analysis  of  the  development  environment  and  its  past  ex- 
perience on  projects  of  similar  size  and  complexity,  CSC  recommends,  in  addition 
to  the  formal  contractual  communication  vehicles  for  reporting  and  review  pro- 
posed in  Section  5.2.3,  the  following  ways  to  enhance  control  within  the  Project: 
weekly  activity  reports,  regular  staff  meetings,  Internal  design  reviews,  docu- 
mentation reviews,  test  material  reviews,  source  code  reviews,  and  informal 
reviews.  These  are  discussed  below. 

• Weekly  Progress  Reports.  Each  week.  Project  personnel  prepare  a 
progress  report  discussing  activities  during  the  week,  planned  future  activities, 
and  problems  encountered  or  anticipated.  All  problems  must  be  accompanied  by 
suggested  alternative  solutions.  The  Project  Manager  analyzes  these  weekly 
reports  to  measure  reported  technical  progress  against  the  planned  progress  doc- 
umented in  the  Project  Milestone  Schedule  and  acts  to  resolve  any  problems  iden- 
tified. 
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• Regular  Staff  Meetings.  At  least  once  a week,  the  Project  Manager 

conducts  project  review  meetings  with  the  Project  Staff.  The  objectives  of  i 

these  meetings  are  to  review  status  and  problems  as  detailed  in  the  Weekly 
Progress  Reports,  to  identify  and  evaluate  pertinent  external  developments  and 
their  potential  impact,  to  discuss  and  resolve  general  project  management  prob- 
lems  (e.g.,  project  communications,  reporting,  procedures);  and  to  call  atten- 
tion to  activities  requiring  special  skills  (e.  g. , short-term  or  quick-response 
application  of  senior  technical  specialists).  These  regular  staff  meetings  are 
augmented  with  phone  calls  to  subcontractors;  conference-type  calls  are  used 
when  necessary. 

• Internal  Design  Reviews.  During  design  activities,  management  or 
designated  technical  personnel  conduct  internal  design  reviews  by  having  de- 
signers "walk  through"  their  designs.  (The  reviewers  will  evaluate  the  design 
and  recommend  improvements  or  modifications. ) Project  management  directs 
action  based  on  these  recommendations.  The  use  of  design  walk-throughs  has 
proved  to  be  highly  effective  in  monitoring  design  status  and  quality  and  in  satis- 
fying needs  for  communication  of  design  information  among  Project  staff  members. 

• Documentation  Reviews.  All  documentation  products  are  submitted 

- 

for  detailed  technical  and  quality  control  review.  Technical  review  is  the  re- 
sponsibility of  the  Technical  Director  or  his  delegated  representative  and  con- 
siders such  factors  as  conformance  to  specifications,  accuracy,  clarity,  and 

completeness.  (Quality  assurance  review  is  concerned  with  format,  organiza-  ' 

■ tion,  clarity,  language,  and  grammar. ) , 

• Test  Material  Reviews.  Following  design  activities,  management 
or  designated  technical  personnel  conduct  internal  reviews  of  test  material  by 
having  the  developers  of  the  material  "walk  through"  the  test  specifications  and 
procedures.  (The  reviewers  will  evaluate  the  planned  tests  and  recommend  ad- 
ditions or  modifications).  Only  after  test  material  has  been  reviewed  and  ap- 
proved by  designated  personnel  can  the  planned  tests  be  executed.  Experience 
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has  demonstrated  the  effectiveness  of  testing  walk-throughs  in  monitoring  test 
status  and  in  ensuring  that  the  tests  planned  are  sufficiently  comprehensive  to 
demonstrate  the  validity  of  both  the  design  and  the  code. 
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• Source  Code  Reviews.  Source  code  is  one  of  the  Development 
Phase  Contractor's  most  important  products.  Therefore,  software  development 
monitoring  procedures  include  walk-throughs  of  source  code  products  by  man- 
agement and  lead  technical  personnel  to  ensure  accuracy  and  conformance  with 
Project  programming  standards.  This  review  of  source  code  is  a significant 
element  of  CSC's  software  development  monitoring  procedures.  Each  module 
must  be  formally  reviewed  and  approved  by  designated  personnel  before  it  can 
be  introduced  into  a System  source  library. 

• Informal  Reviews.  In  addition  to  the  above  formal  monitoring  pro- 
cedures, CSC  places  a great  deal  of  emphasis  on  informal  methods.  These 
methods  rely  on  the  ability  of  responsible  senior  technical  and  management  staff 
members  to  work  closely  with  less  experienced  staff  members  to  check  progress 
and  provide  daily  guidance  and  encouragement  in  person.  This  informal  method 
is  highly  productive  because  it  monitors  progress  on  a very  detailed  level  and 
eliminates  uncertainties  that  might  exist  about  what  progress  is  expected.  A 

derivative  benefit  of  this  personal  contact  is  the  establishment  of  Interpersonal  f 

rapport  throughout  the  Project,  creating  an  environment  that  contributes  to  the 
development  and  retention  of  a highly  efficient,  closely  knit  team. 

5.2.5  Configuration  Management  Plan  » 

Configuration  management  is  a discipline  applying  technical  and  administrative 
direction  and  surveillance  to  (1)  identify  and  document  the  functional  and  physi- 
cal characteristics  of  a configuration  item,  (2)  control  changes  to  those  charac- 
teristics, and  (3)  record  and  report  change-processing  and  implementation 
status.  Configuration  management  is  thus  the  means  through  which  the  integrity 
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and  continuity  of  the  design  and  various  engineering  and  cost  trade-off  decisions 
are  recorded,  communicated,  and  controlled. 

One  of  the  most  important  aspects  of  configuration  management  is  the  concept 
of  baseline  management.  A baseline  is  a document  that  formally  identifies  and 
establishes  the  initial  configuration  identification  of  a configuration  item  at  spe- 

t 

cific  times  during  its  life  cycle.  A baseline  provides  a formal  departure  point 
for  control  of  future  changes  in  performance  and  design.  Usually  three  base- 
lines are  defined:  functional,  allocated,  and  product.  A functional  baseline  is  , 

usually  a Type  A System  Specification,  an  allocated  baseline  is  usually  a Type  B 
Development  Specification,  and  a product  baseline  is  usually  a Type  C Product 
Specification. 

It  is  assumed  that  the  Contract  Data  Requirements  List  (CDRL)  of  the  Develop- 
ment Phase  contract  will  require  the  Development  Phase  Contractor  to  submit  a 
Configuration  Management  Plan  to  the  Government. 

CSC  envisions  the  Configuration  Management  Plan  for  the  development  of  the 
Second  Generation  Comprehensive  Helicopter  Analysis  System  to  be  in  eight  sec- 
tions: Section  1,  Organization;  Section  2,  Configuration  Identification;  Section  3, 

i ' 

Configuration  Control;  Section  4,  Configuration  Status  Accounting;  Section  5, 

Subcontractor/Vendor  Control;  Section  6,  Program  Phasing;  Section  7,  Manage- 
ment Integration  of  Configuration  Management;  and  Section  8,  Configuration 
Audits. 

r 

Section  1,  Organization,  will  summarize  the  Project  organization;  the  configura- 
tion management  organization  and  its  relationship  to  the  Project  organization;  ' 

the  responsibilities  and  authorities  of  the  configuration  management  function; 
the  configuration  management  system;  policies  and  procedures  related  to  con- 
figuration management;  program  support  library  services;  and  technical  library 
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services.  The  responsibilities  of  the  configuration  management  function  are  as 
follows : 

• Preparation  of  the  Configuration  Management  Plan  and,  once 
approved  by  the  Government,  performance  of  audits  to  ensure 
conformance  by  the  Project  organization  to  the  principles  of  the 
plan 

• Review  of  all  CDRL  items  to  ensure  conformance  to  contractual 
configuration  management  requirements 

• Maintenance  of  all  Project  data 

• Review  of  all  configuration  indexes  for  completeness  and  accuracy 

• Preparation  of  Engineering  Change  Proposals  (ECPs),  Advanced 
Change/Study  Notices  (AC/SNs),  and  Specification  Change  Notices 
(SCNs) 

• Review  of  all  proposed  changes,  regardless  of  classification  or 
origin,  after  a baseline  has  been  established 

• Development  and  implementation  of  working  procedures  that  define 
the  methods  to  be  used  for  the  identification  and  control  of  computei 
programs  and  support  documentation 

Section  2,  Configuration  Identification,  will  describe  the  process  of  defining 
and  documenting  the  approved  configuration  of  the  System  throughout  its  life 
cycle  in  terms  of  Type  B5  Development  Specifications  and  Type  C5  Product 
Specifications.  A specification  tree  will  be  used  to  show  the  relationship  between 
and  among  the  specifications.  Specifications  shall  comply  with  the  applicable 
military  standards,  e.g. , MIL-STD-490',  MIL-STD-483,  and  MIL-STD-480.  Be- 
cause of  the  multiorganization  environment  of  the  development  of  the  System, 
interface  control  will  be  described  in  detail.  The  standards  for  assigning  config- 
uration Identification  numbers  to  specifications,  CPCIs,  CPCI  copies,  CPCI 
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versions,  and  magnetic  tapes  and  other  storage  media  will  also  be  presented,  as 
well  as  the  procedures  for  release  of  the  System. 

Configuration  control  is  the  systematic  evaluation,  coordination,  approval  or 
disapproval,  and  implementation  of  proposed  changes  to  an  established  baseline. 
Section  3,  Configuration  Control,  will  discuss  the  preparation  of  ECPs,  AC/SNs, 
and  SCNs  in  accordance  with  MIL-STD-480;  the  content  of  ECPs;  maintenance 
of  the  Type  B5  Development  Specifications  and  Type  C5  Product  Specifications; 
and  configuration  control  of  computer  program  code  (cards,  tapes,  etc). 

Section  4,  Configuration  Status  Accounting,  will  state  the  Development  Phase 
Contractor's  plans  for  application  of  configuration  index  and  status  accounting 
records  for  the  Development  Phase. 

Section  5,  Subcontractor/Vendor  Control,  will  describe  the  methods  CSC  will 
use  to  ensure  that  subcontractor/vendor  practices  adhere  to  the  Project's  Con- 
figuration Management  Plan.  This  section  will  include  the  methods  CSC  will 
use  to  determine  subcontractor/vendor  capability  in  the  configuration  manage- 
ment area. 

Section  6,  Program  Phasing,  will  establish  the  major  milestones  for  implemen- 
tation of  the  Configuration  Management  Plan.  These  include  the  following: 

• Establishing  the  Configuration  Control  Board 

\ 

\ 

• Phasing  for  specification-program  Implementation,  Including  speci- 
fication maintenance 

• Establishing  each  of  the  configuration  Identifications 

• Establishing  interface  control  agreements  with  subcontractors  and 
the  Government 

• Establishing  configuration  index  and  status  accounting  procedures 
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Section  7,  Management  Integration  of  Configuration  Management,  will  describe 
the  integration  of  configuration  management  activities  with  other  Project  manage- 
ment activities.  The  relationship  between  configuration  management  at  the 
CPCI  level  and  its  relationship  to  the  work  breakdown  structure  for  control  of 
work  authorization  and  cost  control  will  be  defined  and  discussed.  This  section 
will  also  provide  detailed  information  about  the  relationship  between  events  crit- 
ical to  configuration  management  and  schedule  of  the  Project  (sequencing  of  design 
reviews,  releases,  audits,  etc.). 

Section  8,  Configuration  Audits,  will  contain  CSC's  plans  for  conducting  both 
functional  and  physical  configuration  audits. 

5.2.6  Documentation  Management  Plan 

Providing  thorough,  high-quality  documentation  is  a principal  Government  objec- 
tive for  the  Second  Generation  Comprehensive  Helicopter  Analysis  System.  Such 
documentation  does  not  simply  happen — it  must  be  well  conceived,  well  planned, 
and  well  executed.  Detailed  planning  for  the  documentation  for  the  Development 
Phase  has  begun  during  the  Predesign  Phase  with  the  Documentation  Plan  in  Sec- 
tion 5.3.3.  The  importance  CSC  attaches  to  documentation  is  illustrated  by  the 
fact  that  the  Detailed  Technical  Approach,  which  is  a part  of  the  System  Develop- 
ment Plan,  organizes  the  work  around  the  principal  document  deliverables.  CSC's 
management  methodology  for  producing  thorough,  high-quality  documentation  em- 
phasizes the  following:  ' 

I i 

• Detailed  planning  and  scheduling 

• Standards  for  document  production 

• Management  reviews  of  all  deliverables 

• Use  of  CSC's  Technical  Publications  Department 

These  four  topics  are  discussed  in  detail  in  the  Baseline  Development  Plan  . 
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The  technical  plans  in  this  section  are  divided  into  major  technical  plans  and  sub- 
ordinate technical  plans.  The  major  technical  plans  presented  here  are  taken,  by 
and  large,  intact  from  the  Baseline  Development  Plan.  The  three  major  technical 
plans  are  the  Quality  Assurance  Plan  (Section  5.3.1),  the  Testing  Plan  (Sec-  ( 

tion  5.  3.2),  and  the  Documentation  Plan  (Section  5.3.3).  There  are  five  subordi- 
nate technical  plans:  the  Data  Processing  Facility  Plan  (Section  5. 3.4.1),  the 
Data  Management  Plan  (Section  5. 3. 4. 2),  the  System  Installation  and  Release  Plan  • 

(Section  5.3.4. 3),  the  Training  Plan  (Section  5. 3. 4. 4),  and  the  Maintenance  Plan 
(Section  5. 3. 4. 5). 

5.3.1  Quality  Assurance  Plan 

This  section  defines  the  quality  assurance  methodology  to  be  used  during  the  De- 
velopment Phase  for  ensuring  satisfactory  design,  implementation,  and  testing. 

Section  5. 3. 1. 1 defines  the  methodology  to  be  used.  Section  5. 3. 1. 2 presents  the 
general  management  approach  to  be  used  to  implement  the  methodology.  Sec- 
tions 5. 3. 1.3,  5. 3. 1.4,  and  5. 3. 1.5  describe  the  application  of  the  methodology 
to  design,  implementation,  and  testing  efforts,  respectively. 

5.3. 1.1  Quality  Assurance  Methodology  t 

The  methodology  for  quality  assurance  of  the  System  includes  the  use  of  the  follow- 
ing: 5, 

r 

1.  Top-down  development 

2.  HIPO  (Hierarchy  plus  Input-Process-Output)  for  design  presentation  ' 

3.  Data  flow  diagrams 

4.  Structured  "walk-throughs" 

5.  Definition  and  enforcement  of  programming  standards 

6.  Development  of  test  specifications  before  coding 

7.  Structured  programming 

8.  Independent  testing 
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Top-down  development  involves  designing,  coding,  and  testing  the  highest  level 
modules  of  a system  first,  in  contrast  to  the  more  common  methodology  used  in 
the  past — bottom-up  development.  The  top-down  approach  has  the  benefits  of  giv- 
ing the  critical  modules  near  the  top  of  the  module-calling  hierarchy  of  the  soft- 
ware system  the  most  testing,  thus  providing  earlier  warning  of  problems  with  the 
interfaces  between  and  among  modules  and  groups  of  modules. 

HIPO  is  an  approach  to  functional  specification  and  documentation  of  software  de- 
signed in  a top-down  fashion.  Each  function  is  designed  using  an  Input,  Process, 
Output  (IPO)  diagram,  which  lists  the  input  and  output  and  specifies  the  process- 
ing to  be  carried  out.  A hierarchical  visual  table  of  contents  diagram  relates  the 
IPO  diagrams  and  shows  not  only  the  functions  and  subfunctions  to  be  carried  out 
but  also  the  relationships  between  them.  The  hierarchical  structure  of  HIPO  is 
well  suited  to  the  presentation  of  a top-down,  hierarchical  design  created  by 
starting  at  the  top  and  subdividing  into  increasingly  lower  levels  of  detail.  HIPO 
has  been  used  by  CSC  throughout  the  Predesign  Phase. 

Data  flow  diagrams  are  used  to  show  how  System-level  data  flows  through  the 
System  from  function  to  function  or  subfunction  to  subfunction.  Data  flow  diagrams 
show  the  relationships  between  the  software  elements  of  the  System  design  and  the 
data  to  be  processed  by  the  System.  A form  of  data  flow  diagrams  is  presented 
in  Section  2.5  to  illustrate  System  Command  Sequences  and  data  flow. 

A structured  "walk-through"  is  a review  session  in  which  the  originator  of  the 
design  material,  the  test  material,  or  code  "walks"  the  reviewers  through  the  de- 
sign, the  test  materials,  or  the  code  in  a step-by-step  fashion  to  simulate  the 
function  under  investigation.  The  intent  of  a structured  "walk-through"  is  to  de- 
tect problems  in  development  as  early  as  possible,  when  they  are  least  expensive 
to  correct.  The  effectiveness  of  structured  "walk-through"  has  been  demonstrated 
repeatedly. 
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Programming  standards  not  only  affect  the  legibility  and  reliability  of  software-as- 
written  but  also  affect  design  concepts.  The  effectiveness  of  programming  stand- 

■ 

ards  is  proportional  to  their  quality  and  management's  commitment  to  their 
enforcement.  Therefore,  programming  standards  (in  the  form  of  the  Program- 
ming Standards  for  the  Second  Generation  Comprehensive  Helicopter  Analysis  Sys- 
35 

tern  ) will  be  finalized  early  and  enforced  rigorously  throughout  the  Development 
Phase.  The  Automated  Code  Auditor  Package  (Section  2.4. 1.5)  aids  in  the  objec- 
tive measurement  of  the  degree  of  adherence  of  the  source  code  to  the  standards. 

Because  test  specifications  are  most  effective  if  based  on  design  requirements 
rather  than  the  software  as  coded,  they  are  developed  before  the  corresponding 
code  is  written.  In  this  way,  errors  are  surfaced  early  when  they  are  less  costly 
to  correct. 

Structured  programming  is  a style  of  programming  in  which  the  structure  of  a 
module  (that  is,  the  interrelationships  of  its  parts)  is  made  as  clear  as  possible 
by  using  a restricted  number  of  control  logic  structures.  An  Important  character- 
istic of  a module  written  in  this  style  is  that  it  can  be  read  in  sequence,  from  top 
to  bottom,  with  little  or  no  skipping  around  through  the  code,  which  tends  to  be 
typical  of  other  programming  styles.  This  top-to-bottom  characteristic  extends 
the  concept  of  top-down  design  to  the  actual  code  of  each  module.  A module  writ- 
ten according  to  structured  programming  principles  not  only  has  a structure  but 
also  clearly  exhibits  that  structure. 

- r 

Independent  testing  is  a concept  that  maximizes  objectivity  of  testing.  This  objec- 
tivity minimizes  bias  often  found  when  the  person  who  coded  the  software  also  tests 

9 

the  software.  Thus,  independent  testing  increases  the  assurance  that  the  software 
satisfies  the  intended  requirements  of  the  System. 

5. 3. 1. 2 Quality  Assurance  Management  Plan  * 

CSC’s  overall  quality  assurance  management  plan  is  based  on  the  premise,  which 
has  been  repeatedly  demonstrated  to  be  true,  that  maximizing  the  objectivity  of  the 
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personnel  who  review  products  significantly  enhances  the  quality  of  those  products. 

This  objectivity  increases  the  probability  of  the  development  of  a reliable  and  i 

acceptable  System. 

The  key  element  of  the  plan  affecting  quality  assurance  is  the  establishment  of  a 
Product  Assurance  Technical  Area  independent  of  the  Technology  Analysis  and  De- 
sign and  Software  Technical  Areas.  The  Product  Assurance  Technical  Area 
defines  and  audits  the  enforcement  of  design,  programming,  testing,  and  documen- 
tation standards;  independently  reviews  software  designs;  and  independently  de- 
fines and  conducts  integration  and  acceptance  tests.  The  Product  Assurance 
Technical  Area  also  conducts  staff  training  to  ensure  that  all  members  of  the  Proj- 
ect are  aware  of,  and  understand,  the  quality  assurance  methodology  to  be  em- 
ployed in  System  design,  implementation,  and  testing. 

Another  key  element  of  CSC's  quality  assurance  management  plan  is  the  use  of 
structured  "walk-throughs"  of  design,  test  specifications,  and  code.  The  princi- 
pal participants  in  design  and  test  "walk-throughs"  are  Project  staff  members 
from  technical  areas  not  involved  in  the  design  being  reviewed.  Structured  "walk- 
throughs" are  also  emDloved  by  CSC  at  review  meetings  with  the  Government. 

The  principal  participants  in  code  and  test  "walk-throughs"  are  programmers  not 

| 

involved  with  the  code  being  reviewed. 

5. 3. 1. 3 Quality  Assurance  Design  Methodology 

CSC 's  approach  for  designing  the  System  is  based  on  the  concept  of  top-down  de- 
velopment at  all  design  levels,  from  the  System  level  down  to,  and  including,  the 
module  level.  H3PO  and  data  flow  diagrams  are  used  as  principal  design  presen- 
tation methods  at  the  subsystem,  package,  and  subpackage  levels.  Module  designs, 
on  the  other  hand,  are  expressed  using  a design  language  called  Program  Design 
Language  (sometimes  called  pseudocode  in  the  literature),  which  is  based  upon  the 
structured  programming  control  logic  structures  described  in  the  response  to 
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critical  issue  9 in  Section  HI.  1.4. 9 of  the  Specification  Revisions,  Initial  Develop- 
ment Plan,  and  Design  Analysis  Report,  called  briefly  the  Task  I Interim  Tech- 
nical Report.  Specifically,  CSC  plans  to  present  module  designs  in  terms  of  the 
actual  module  prologs  to  be  included  in  the  module  source  decks.  Structured  de- 
sign "walk-throughs"  will  be  used  to  review  all  designs  at  all  design  levels. 

5. 3. 1. 4 Quality  Assurance  Implementation  Methodology 

Immediately  after  contract  award,  CSC  plans,  as  indicated  in  Section  5.2.1,  to  . 

review  the  set  of  programming  standards  supplied  by  the  Government  for  the  Sys- 
tem: Programming  Standards  for  the  Second-Generation  Comprehensive  Helicopter 
35 

Analysis  System.  These  standards  are  based  on  the  work  done  in  Task  I of  this 

contract.  Also  to  be  reviewed  is  the  Nomenclature  of  the  Second-Generation  Com- 

36 

prehensive  Helicopter  Analysis  System,  which  contains  definitions  of  all  the 
mathematical  symbols  to  be  used  for  the  System. 

For  each  module,  conformance  to  the  contract-specified  programming  and  nomen- 
clature standards  is  assessed,  and  nonapproved  deviations  are  corrected  before 
testing  on  the  computer  commences.  This  is  accomplished  using  the  Automated 
Code  Auditor  Package  of  the  Support  Complex  and  by  manual  inspection.  The  de- 
livery of  a module  to  the  Government  is  accompanied  by  a certification  of  the  ■ > 

module's  conformance  to  the  defined  standards. 

j 

Before  coding  begins  on  any  module,  a module  test  specification  is  generated. 

This  early  generation  of  module  test  material  minimizes  the  subjectivity  that  would  t 

have  been  introduced  had  the  module  test  specification  been  written  based  on  the  f 

code.  When  the  programmer  completes  the  module  code,  a code  and  test  specifi- 
cation "walk-through"  is  conducted  to  ensure  that  the  code  correlates  with  the  ap- 
proved design,  that  the  code  conforms  to  the  approved  programming  standards,  , 

and  that  the  planned  tests  force  the  execution  of  all  decision  paths  and  includes 
test  values  critical  to  the  functioning  of  the  module. 
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5. 3. 1. 5 Quality  Assurance  Testing  Methodology 

CSC  plans  to  apply  the  concepts  of  top-down  development  to  testing  as  well  as  de-  i 

sign  and  coding.  This  approach  not  only  ensures  early  and  exhaustive  testing  of 
the  critical  nucleus  modules  of  both  the  Executive  Component  and  the  Technology 
Component,  but  also  minimizes  the  amount  of  special  test  software  needed,  thus 
reducing  costs.  The  scaffolding  characteristic  of  top-down  development  automa- 
tically provides  a test  environment  for  all  but  general-purpose  (usually  mathe- 
matically oriented)  modules. 

The  approach  planned  for  System  testing  is  presented  in  Section  5.3.2  of  this 
report.  There  are  four  levels  of  testing:  module,  CPCI,  integration,  and  accept- 
ance. All  decision  paths,  module  interfaces,  and  CPCI  interfaces  are  tested. 

Integration  and  acceptance  testing  are  independently  specified  and  conducted  by 
the  Product  Assurance  Technical  Area.  Test  coverage  in  terms  of  decision  paths, 
module  interfaces,  and  CPCI  interfaces  is  objectively  monitored  by  an  automated 
decision  path  monitoring  test  tool,  the  Decision  Path  Monitor  Package.  Tests  to 
identify  the  central  processing  unit  (CPU)  timing  characteristics  and  computer  re- 
source requirements  for  each  software  element  are  conducted  during  CPCI,  inte- 
gration, and  acceptance  testing.  Tests  for  accuracy  are  conducted  at  all  testing 
levels.  Tests  to  demonstrate  the  adequacy  of  the  analysis  upon  which  the  System 
design  is  based  are  conducted  during  integration  and  acceptance  testing.  At  all 
testing  levels,  test  specifications,  descriptions,  procedures,  and  reports  are  pro- 
vided to  the  Government  as  a means  of  monitoring  the  progress  and  quality  of 
System  development. 

. 

5.3.2  Testing  Plan 

This  section  defines  the  overall  testing  objectives  for  the  Second  Generation  Com- 
prehensive Helicopter  Analysis  System  and  the  general  approaches  selected  to 
accomplish  these  objectives.  Section  5. 3. 2.1  defines  testing  objectives  and  con- 
cepts; Section  5. 3. 2. 2 describes  the  management  plan  to  ensure  that  these 
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objectives  are  met;  Section  5. 3. 2. 3 specifies  the  documentation  necessary  to 
evaluate  the  validity  and  progress  of  the  testing  efforts;  Section  5. 3. 2. 4 describes 
the  automated  tools  to  be  used  to  support  testing;  Section  5. 3. 2. 5 defines  the 
procedures  involved  in  resolving  problems  encountered  during  testing;  and  Sec- 
tion 5. 3. 2. 6 describes  the  software  library  control  methodology.  This  System 
Testing  Plan  satisfies  the  testing  requirements  defined  in  Section  4 {Quality  Assur- 
ance Provisions)  of  the  Baseline  Type  A System  Specification  and  conforms  to  the 
Software  Testing  Guidance  in  Chapter  3 of  Reference  37. 

5. 3. 2. 1 Testing  Objectives  and  Concepts 

The  principal  objectives  of  System  testing  are  threefold:  to  verify  the  accuracy 
of  the  code,  identify  the  central  processing  unit  (CPU)  time  and  other  computer 
resource  utilization  characteristics  of  the  System  (e.g. , I/O  time),  and  verify  the 
adequacy  of  the  analysis  upon  which  the  System's  design  is  based.  Four  levels  of 
testing  are  employed  to  satisfy  these  objectives:  module  testing,  CPC1  testing, 
integration  testing,  and  acceptance  testing.  These  levels  proceed  from  the  most 
detailed,  module  testing,  to  the  most  comprehensive,  acceptance  testing.  The 
characteristics  of  the  tests  at  each  level  are  defined  in  terms  of  both  the  overall 
objectives  of  the  testing  and  the  orientation  of  the  test  (i.e. , the  basis  for  the  as- 
sessment of  success  or  failure).  Table  5 depicts  the  characteristics  of  the  tests 
at  each  testing  level,  and  Figure  38  illustrates  the  relationship  of  each  testing 
level  to  the  software  hierarchy. 

Accuracy  of  coding  is  verified  at  all  levels  of  testing.  The  CPU  and  other  compu- 
ter resource  utilization  characteristics  are  identified  during  CPCI,  integration, 
and  acceptance  testing.  The  adequacy  of  the  analysis  upon  which  the  System  de- 
sign is  based  is  verified  during  CPCI,  integration,  and  acceptance  testing. 

37RESEARCH  AND  DEVELOPMENT  SOFTWARE  ACQUISITION  - A GUIDE  FOR 
THE  MATERIEL  DEVELOPER,  AMCP  70-4,  Army  Materiel  Command,  Head- 
quarters U.  S.  Army  Materiel  Command,  September  1974. 
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The  orientation  of  the  tests  varies  at  each  testing  level.  Module  tests  are  based 
upon  the  requirements  defined  in  the  Type  C5  Product  Specifications;  CPCI  tests 
are  based  upon  the  requirements  defined  in  the  Type  B5  Development  Specifica- 
tions, supplemented  by  the  Type  C5  Product  Specifications;  and  integration  and 
acceptance  tests  are  based  upon  the  requirements  defined  in  the  Type  B5 
Development  Specifications,  supplemented  by  the  Type  A System  Specification. 

The  orientation  of  the  tests  defines  the  basis  of  both  test  design  and  test  evalua- 
tion. 

The  four  levels  of  testing  to  be  employed  not  only  ensure  early  detection  of  prob- 
lems but  also  provide  an  orderly  methodology  for  mapping  the  overall  objectives 
of  the  testing  and  the  System  specifications  into  the  System  testing  effort. 

5. 3. 2. 2 Test  Management 

Setting  objectives  and  defining  concepts  for  testing  do  not  ensure  that  the  objec- 
tives will  be  met  and  the  concepts  realized.  Effective  management  of  the  testing 
is  essential  to  meeting  the  defined  objectives.  Table  6 defines  the  planned  ex- 
tent of  Government  Project  Office  involvement  in  monitoring  the  progress  of  Sys- 
tem testing.  It  also  defines  the  interrelationships  among  the  Project  technical 
areas  in  the  testing  effort.  CSC's  approach  to  managing  System  testing  efforts  is 
to  identify  well-defined  organizational  responsibilities,  ensure  total  Project  in- 
volvement in  testing,  provide  sufficient  checkpoints  to  the  Government  for  evaluat- 
ing the  efficacy  and  progress  of  System  development,  and  apply  detailed  plans  for 
the  time-phased  integration  of  development  and  testing  efforts. 

The  three  line  organizations  of  the  proposed  Project  organization  (Section  5. 1)  are 
the  Technology  Analysis  and  Design  Technical  Area,  the  Software  Technical  Area, 
and  the  Project  Assurance  Technical  Area.  The  Technology  Analysis  and  Design 
Technical  Area  provides  direct  helicopter  analysis  support  to  the  other  two  areas 
during  all  levels  of  testing.  The  support  of  this  technical  area  is  most  critical 
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Table  6.  Involvement  of  the  Government  Project  Office  and  Project 
Technical  Areas  in  System  Testing 
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during  integration  and  acceptance  testing  because,  during  these  two  phases,  the 
adequacy  of  the  analysis  upon  which  the  System  design  is  based  is  evaluated. 

i 

The  Software  Technical  Area  is  directly  responsible  for  all  module  and  CPCI  test- 
ing. However,  the  Product  Assurance  Technical  Area  reviews  and  monitors  the 
module  and  CPCI  testing  efforts  to  ensure  that  sufficient  tests  are  planned  and  that 
the  tests  accomplish  their  goals.  Test  specifications  and  reports  generated  dur- 
ing module  and  CPCI  testing  will  be  made  available  for  informal  review  by  the 
Government,  upon  request,  as  a means  of  verifying  the  progress  of  System  de- 
velopment. 

Hie  Product  Assurance  Technical  Area  is  directly  responsible  for  integration  and 
acceptance  testing.  The  independence  of  this  technical  area  from  the  other  two 
provides  the  objectivity  necessary  to  demonstrate  that  the  System  performs  in  ac- 
cordance with  the  Government-approved  specifications.  In  addition  to  the  informal 

review  and  review/approval  guidelines  during  integration  and  acceptance  testing 

3? 

suggested  by  AMCP  70-4,  it  is  recommended  that  the  Government  monitor  and 
participate  in  the  actual  performance  of  the  approved  acceptance  tests. 

Figure  39  illustrates  the  time-phased  integration  of  development  and  testing  ef- 
forts planned  by  CSC  for  the  System.  Preparations  for  each  testing  level  repre- 
sent parallel  activities,  thus  maximizing  the  level  of  objectivity  inherent  at  each 
level  of  testing  and  minimizing  the  effects  of  serialization.  The  time-phased  in- 
tegration of  development  and  testing  efforts,  when  combined  with  the  Project  or-  . L 

ganizational  involvement  in  System  testing  planned  by  CSC,  ensures  both  a reliable 
System  testing  schedule  and  reliable  software  product. 

5. 3. 2. 3 Test  Documentation 

Table  7 shows  the  test  documentation  which  is  made  available  to  the  Government 
during  all  phases  of  System  testing.  Test  documentation  represents  the  principal 
means  whereby  the  Government  and  the  Development  Phase  Contractor  can  verify 
the  progress  of  System  development,  determine  if  there  are  potential  difficulties 


or  trouble  areas  that  could  affect  subsequent  testing  or  developmental  efforts,  and 
qualify  the  acceptability  of  the  System. 

5. 3. 2. 4 Test  Tools 

In  the  past,  tools  for  testing  software  were  synonymous  with  simulation  tools. 
However,  of  at  least  equal  importance  in  today's  software  development  environment 
are  automated  tools  that  objectively  measure  the  scope  of  the  testing  and  objec- 
tively verify  the  conformance  of  software  to  defined  programming  standards. 

Table  8 shows  the  planned  use  of  these  two  tools  throughout  the  testing  effort. 

Before  module  testing  begins,  the  Automated  Code  Auditor  Package,  augmented 
by  manual  inspection,  is  used  to  determine  each  module's  conformance  to  pro- 
gramming standards.  All  nonapproved  deviations  are  corrected  before  module 
testing  begins.  The  same  process  is  independently  performed  by  the  Product  As- 
surance Technical  Area  before  integration  testing  begins. 

The  Decision  Path  Monitor  Package  is  used  during  module  testing  to  ensure  that 
every  decision  path  (a  combination  of  a branch  point  and  one  of  its  dependent  proc- 
essing paths)  has  been  tested.  During  CPCI  testing,  the  Decision  Path  Monitor 
is  used  to  ensure  that  every  module  invocation  within  each  CPCI  has  been  tested. 
During  integration  testing,  the  Decision  Path  Monitor  is  used  to  verify  that  all  in- 
terface points  between  CPCIs  have  been  tested.  This  use  of  the  Decision  Path 
Monitor  for  module,  CPCI,  and  integration  testing  provides  an  objective  method 
for  measuring  the  ultimate  confidence  level  achieved  in  the  operational  reliability 
of  the  System. 

5. 3 . 2 . 5 Resolution  of  Errors 

Errors  encountered  during  testing  and  the  costs  attributable  to  their  resolution 
contribute  more  to  the  unpredictability  of  testing  schedules  than  any  other  element 
of  System  development.  The  software  development  methodology  of  top-down 
structured  design  and  implementation,  combined  with  rigorous  enforcement  of 
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design  and  programming  standards,  represents  CSC's  approach  to  minimizing  the 
number  of  problems  encountered  and  the  cost  of  resolving  them.  However,  this 
does  not  eliminate  the  need  to  define  a methodology  for  problem  resolution. 

The  most  important  element  of  this  problem  resolution  methodology  is  explicitly 
defining  the  organizational  involvements  in  problem  identification,  problem  resolu- 
tion, resolution  verification,  and  resolution  integration  into  the  System.  Table  9 
shows  the  planned  organizational  involvement  in  each  problem  resolution  effort  at 
each  stage  of  testing.  During  module  and  CPC1  testing,  problem  detection  and  res- 
olution are  primarily  the  responsibility  of  the  organizations  involved  in  the  testing, 
namely  the  Technology  Analysis  and  Design  Technical  Area  and  the  Software  Tech- 
nical Area.  No  direct  involvement,  beyond  consulting  support,  by  the  Product 
Assurance  Technical  Area  is  envisioned. 

However,  during  integration  and  acceptance  testing,  the  Product  Assurance  Tech- 
nical Area  assumes  a major  role  because  of  its  overall  responsibility  for  integra- 
tion and  acceptance  testing.  Product  Assurance  Technical  Area  personnel  will  be 
the  principal  initiators  of  integration  and  acceptance  testing  problem  reports  and 
will  be  responsible  for  integrating  the  resolutions  into  the  System.  The  analysis 
and  resolution  of  the  individual  problems  by  the  Technology  Analysis  and  Design 
and  the  Software  Technical  Areas  are  also  monitored  by  the  Product  Assurance 
Technical  Area  to  ensure  that  the  real  problem,  rather  than  just  its  symptoms, 
is  addressed.  This  monitoring  of  the  analysis  and  resolution  efforts  provides  the 
information  needed  to  plan  for  the  retesting  necessary  when  the  source  code  and 
other  products  of  the  resolution  are  delivered  to  the  Product  Assurance  Technical 
Area  for  integration  into  the  System  configuration.  This  monitoring  also  provides 
the  information  needed  to  keep  the  Government  abreast  of  the  continuing  progress 
of  the  testing  and  of  potential  trouble  areas  that  could  affect  subsequent  testing  or 
developmental  efforts. 
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5.3.2. 6 Software  Library  Controls 

To  ensure  a responsive  environment  for  testing,  effective  control  of  software  li- 
braries must  be  provided.  CSC  plans  to  establish  five  levels  of  software  libraries: 
operational,  acceptance,  integration,  CPCI,  and  module.  The  operational 
libraries  reflect  die  source,  object,  and  executable  code  of  System  releases  ac- 
cepted by  the  Government  for  operational  use.  The  acceptance  libraries  reflect 
the  differences  between  the  current  operational  release  of  the  System  and  the  re- 
lease currently  undergoing  acceptance  testing.  The  integration  libraries  reflect 
the  differences  between  the  version  of  the  System  undergoing  acceptance  testing 
and  the  version  undergoing  CPCI  testing.  The  CPCI  libraries  reflect  the  differ- 
ences between  the  version  of  the  System  undergoing  integration  testing  and  the 
CPC  Is  being  tested  in  the  Software  Technical  Area.  The  module  libraries  will  re- 
flect the  modules  not  yet  ready  for  inclusion  in  the  CPCI  libraries  for  CPCI  test- 
ing. 

All  software  libraries  are  accessible  to  all  Project- related  personnel  using  the 
host  development  computers.  This  includes  personnel  from  the  Development 
Phase  Contractor,  integrated  team  member  subcontractor,  CPCI  subcontractors, 
the  Government,  the  Government/Industry  Working  Group,  and  the  Technical  Ad- 
visory Group.  Modifications  to  the  operational  libraries  require  advance  Govern- 
ment approval.  However,  the  operational,  acceptance,  and  integration  libraries 
must  be  protected  from  unplanned  modification.  Specifically,  these  three  libraries 
are  updateable  only  by  specifically  Identified  personnel  within  the  Product  Assur- 
ance Technical  Area.  The  CPCI  and  module  libraries  are  controlled  exclusively 
by  the  Software  Technical  Area  because  these  libraries  reflect  the  testing  under 
their  responsibility. 

This  proven  software  library  structure  minimizes  the  use  of  valuable  peripheral 
disk  storage,  because  each  set  of  libraries  reflects  only  differences  from  the  li- 
brary higher  in  the  hierarchy  of  libraries.  This  structure  also  automatically  pro- 
vides a simple  method  for  identifying  differences  between  succeeding  versions 


288 


of  the  System.  Lastly,  the  separation  of  responsibility  in  terms  of  library  con- 
tent places  the  responsibility  in  the  technical  area  that  is  actually  responsible  for 
the  version  of  the  System  reflected  in  the  libraries. 

5.3.3  Documentation  Plan 

CSC’ s approach  to  the  preparation  and  maintenance  of  System  documentation  en- 
sures that  documentation  is  prepared  as  development  progresses,  minimizes 
documentation  content  redundancy  (and  hence  costs),  automatically  results  in  the 
documentation  needed  for  future  System  maintenance  without  costly  reformatting, 
and  is  compatible  with  the  software  engineering  concepts  of  top-down  structured 
design.  Implementation,  and  testing. 

38 

Based  on  an  analysis  of  the  documentation  requirements  of  MIL-STD-490  (sup- 

39  40 

plemented  by  MIL-STD-483  ) and  DoD  4120. 17 -M  for  computer  software  sys- 
tems, a documentation  plan  has  been  generated  that  integrates  these  two  different 
sets  of  documentation  requirements  into  one  integrated  and  nonredundant  set  of 
documents  consisting  of  the  following  seven  documents: 

1 . Type  B5  Computer  Program  Development  Specification 

2.  Type  C5  Computer  Program  Product  Specification 

3.  Data  Base  Specification 

4.  User's  Manual 

5.  System  Maintenance  Manual 

6.  Test  and  Implementation  Plan 

7.  Test  Analysis  Report 

38 

SPECIFICATION  PRACTICES,  MIL-STD-490,  U.S.  Department  of  Defense, 
October  1968. 

39 

CONFIGURATION  MANAGEMENT  PRACTICES  FOR  SYSTEMS,  EQUIPMENT, 
MUNITIONS,  AND  COMPUTER  PROGRAMS,  MIL-STD-483,  U.S.  Department 
of  Defense,  December  1970. 

40 

AUTOMATED  DATA  SYSTEM  DOCUMENTATION  STANDARDS  MANUAL,  DoD 
Manual  4120. 17-M,  U.S.  Department  of  Defense,  December  1972. 


Subsequent  subsections  of  Section  5.3.3  present  the  outlines  planned  for  these 
seven  documents  and  describe  the  recommended  outline  modifications  to  MIL- 

OQ  40 

STD-490  and  DoD  Manual  4120. 17 -M  needed  to  minimize  redundancy  and  to 
allow  a smooth  transition  from  development  documentation  to  maintenance  docu- 
mentation. 

The  most  important  document  to  be  produced  is  the  Type  B5  Computer  Program 
Development  Specification  because  it  formally  establishes  all  the  requirements 
that  a CPCI  is  to  satisfy.  The  Type  C5  Computer  Program  Product  Specification, 
supplemented  by  the  Data  Base  Specification,  actually  represents  the  Configuration 
Item  accepted  by  the  Government  in  the  sense  that  it  is  a one-to-one  reflection  of 
the  software  elements  in  the  delivered  Configuration  Item  and  is  therefore  the 
prime  instrument  against  which  future  software  modifications  are  measured.  The 
User’s  Manual  and  System  Maintenance  Manual  are  primarily  aimed  at  providing 
System  users  and  maintenance  programmers,  respectively,  with  the  information 
needed  to  use  and  maintain  the  System.  The  Test  and  Implementation  Plan  and 
the  Test  Analysis  Report  provide  the  information  needed  by  the  Government  to 
determine  whether  or  not  the  delivered  CPCI  does  in  fact  satisfy  the  requirements 
defined  in  the  Type  B5  Computer  Program  Development  Specification.  In  addi- 
tion, these  same  two  documents  provide  baselines  for  verifying  the  impact  of 
future  modifications,  and  hence  are  also  critical  to  the  Maintenance  Phase. 

As  mentioned  in  Section  5.3. 1,  Quality  Assurance  Plan,  CSC  plans  to  use  four 
modem  software  design  presentation  concepts:  HIPO  (Hierarchy  Plus  Input,  Proc- 
ess, Output)  diagrams,  data  flow  diagrams  to  illustrate  the  relationship  between 
processes,  module  design  specifications  embedded  in  source  decks,  and  a struc- 
tured Program  Design  Language  to  describe  module  flow  in  lieu  of  module  flow 
diagrams.  HIPO  and  data  flow  diagrams  are  included  in  the  Type  B5  Computer 
Program  Development  Specification  and  Type  C5  Computer  Program  Product  Spec- 
ification to  define  all  functional  requirements  down  to  the  module  level  and  to  illus- 
trate the  relationships  among  the  functional  requirements.  All  module  design 
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specifications  and  flow  descriptions  (that  are  presented  in  Program  Design  Lan- 
guage) are  included  as  comment  cards  in  a module  prolog  in  each  module  source 
deck.  A listing  of  the  module  prolog  will  be  included  in  the  Type  C5  Computer 
Program  Product  Specification  as  the  method  of  presenting  the  functional  descrip- 
tion of  the  module. 

CSC  plans  to  maintain  a single  set  of  the  seven  documents  mentioned  above  and 
described  in  more  detail  below.  Because  multiple  CPCIs  will  be  developed  over 
the  lifetime  of  the  System,  multiple  sets  of  technical  documentation  could  result. 
However,  when  a CPCI  is  integrated  into  the  System,  the  CPCI  (software  and  its 
associated  documentation)  ceases  to  be  an  independent  entity.  Rather,  the  func- 
tional characteristics  of  the  System  to  date  will  have  changed  to  reflect  the 
integrated  CPCI.  All  maintenance  and  modification  efforts  subsequent  to  the  in- 
tegration of  a CPCI  must  therefore  be  based  not  on  a System  of  independent  CPCIs 
but  rather  on  a System  with  a set  of  capabilities  and  software  reflecting  all  CPCIs 
integrated  into  the  System  to  date.  If  future  maintenance  efforts  were  based  on 
multiple  sets  of  documents,  a severe  schedule  and  cost  impact  would  result.  What 
is  needed  is  a single  integrated  set  of  baseline  technical  documents  reflecting  all 
integrated  CPCIs.  It  is  this  requirement  that  CSC  plans  to  satisfy  by  maintaining 
a single  set  of  the  seven  documents  mentioned  earlier. 

It  is  recognized  that,  for  each  CPCI  provided  by  the  Government  or  by  a CPCI  sub- 
contractor, a separate  Type  B5  Computer  Program  Development  Specification  and 
Type  C5  Computer  Program  Product  Specification  are  required.  As  each  of  these 
documents  is  accepted  by  the  Government,  it  is  integrated  into  the  Baseline  Type 
B5  Computer  Program  Development  Specification  document  and  the  Baseline 
Type  C5  Computer  Program  Product  Specification  document.  Therefore,  these 
baseline  specifications  will,  at  the  conclusion  of  the  Development  Phase,  reflect 
the  specifications  of  the  complete  Second  Level  Release  of  the  System.  All  updates 
to  the  Data  Base  Specification,  User's  Manual,  and  System  Maintenance  Manual 
provided  by  the  Government  and  by  CPCI  subcontractors  will  be  integrated  by  the 


Development  Phase  Contractor  Into  the  Baseline  Data  Base  Specification,  the  Base- 
line User's  Manual,  and  the  Baseline  System  Maintenance  Manual.  In  addition, 
the  test  specifications,  descriptions,  procedures,  and  analysis  reports  supplied 
in  the  Test  and  Implementation  Plan  and  Test  Analysis  Report  for  each  CPCI  by 
the  Government  or  by  a CPCI  subcontractor  is  integrated  into  the  Baseline  Test 
and  Implementation  Plan  and  the  Baseline  Test  Analysis  Report.  To  minimize  the 
costs  associated  with  this  documentation  integration  effort,  the  outlines  and  stand- 
ards for  the  baseline  documents  will  be  the  same  as  those  identified  below  for  in- 
dividual CPC  Is.  This  documentation  integration  effort  therefore  allows  a smooth 
transition  from  development  to  maintenance. 

5. 3. 3. 1 Type  B5  Computer  Program  Development  Specification 

The  purpose  of  the  Type  B5  Computer  Program  Development  Specification  is  to 
formally  establish  all  the  requirements  for  performance,  design,  test,  and  quali- 
fication of  a Second  Generation  Comprehensive  Helicopter  Analysis  Sytem  CPCI. 
This  specification  formally  establishes  all  the  requirements  that  the  CPCI  is  to 
satisfy,  i.e. , it  defines  CPCI  acceptance/rejection  criteria.  Following  Govern- 
ment review  and  approval,  any  change  and/or  deviation  from  the  requirements 
specified  in  the  Type  B5  Computer  Program  Development  Specification  are  for- 
mally approved  by  the  Government  through  an  Engineering  Change  Proposal. 

No  deviations  from  the  outline  of  the  Type  B5  Computer  Program  Development 

38  39 

Specification,  as  presented  in  MIL-STD-490  and  MIL-STD-483,  are  planned. 
However,  several  additions  are  planned.  Section  4.2,  Test  Requirements,  will 
be  expanded  to  Include  (a)  module  and  CPCI  testing  (Internal  developer  testing)  re- 
quirements (this  will  be  done  in  Sections  4.2. 1 and  4.2.2,  respectively)  and  (b)  in- 
tegration testing  (Preliminary  Qualification  Testing)  requirements  (this  will  be 
done  in  Section  4.2.3).  hi  addition,  six  appendixes  are  specified.  Appendixes  I 
and  n (Sections  10  and  20)  will  specify  deviations  to  Section  3 for  the  Second  Level 
and  First  Level  Release  capabilities,  respectively.  Appendix  in  (Section  30)  will 
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include  definitions  of  terms  used  elsewhere  within  the  Computer  Program  Develop- 
ment Specification.  Appendix  IV  (Section  40)  will  contain  mathematical  derivations 
referenced  elsewhere  within  the  Computer  Program  Development  Specification. 
Appendixes  V and  VI  (Sections  50  and  60)  will  define  the  programming  and  design 
standards  to  be  followed  by  the  CPCI  contractor  in  designing  and  implementing  the 

CPCI  software.  Programming  standards  will  conform  to  Programming  Standards 

35  . 

for  the  Second  Generation  Comprehensive  Helicopter  Analysis  System.  Appen- 
dixes III  to  VI  are  especially  important  to  the  success  of  the  Second  Generation 
Comprehensive  Helicopter  Analysis  System  because  the  System  will  not  be  devel- 
oped as  a single  CPCI;  rather,  it  will  evolve  from  multiple  CPCIa.  Consistency 
is  therefore  of  paramount  importance  to  the  Maintenance  Phase.  The  primary 
function  of  Appendixes  HI  to  VI  is  to  ensure  consistency  in  terminology,  mathemat- 
ical derivations,  programming,  and  design  for  the  system.  Without  such  consist- 
ency, maintenance  could  become  a costly  and  protracted  effort. 

TYPE  B5  COMPUTER  PROGRAM  DEVELOPMENT  SPECIFICATION 


Table  of  Contents 

SECTION 

1. 

SCOPE 

1.1 
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Functional  Summary 
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REQUIREMENTS 

3.1 

Computer  Program  Definition 

3.1.1 

Interface  Requirements 

3. 1.1.1 

Interface  Block  Diagram 

3. 1.1. 2 

Detailed  Interface  Definition 
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SECTION 

3 (Cont'd) 

3.2 

Detailed  Functional  Requirements 

3. 2.  i 

Function  i j 

3.2.1. 1 

3. 2.1.2 

Inputs  ( one  set  for  each  function 

Processing  < 

3. 2.1.3 

Outputs  ) 

3. 2.n*. 

Special  Requirements 

3.2.n*.  1 

Human  Performance 

3. 2.  n*.  2 

Government-Furnished  Property  List 

3.3 

Adaptation 

3.3.1 

General  Environment 

3,3.2 

System  Parameters 

3.3.3 

System  Capacities 

SECTION 

4. 

QUALITY  ASSURANCE  PROVISIONS 

4.1 

Introduction 

4.2 

Test  Requirements 

4.2.1 

Module  Testing  (new) 

4.2.2 

CPCI  Testing  (new) 

4.2.3 

Integration  Testing  (new) 

4.3 

Acceptance  Test  Requirements 

SECTION 

5. 

PREPARATION  FOR  DELIVERY 

SECTION 

6. 

NOTES 

SECTION 

10. 

APPENDIX  I,  SECOND  LEVEL  CAPABILITY  (NEW) 

SECTION 

20. 

APPENDIX  n,  FIRST  LEVEL  CAPABILITY  (NEW) 

SECTION 

30. 

APPENDIX  m,  DEFINITIONS  OF  TERMS  (NEW) 

SECTION 

40. 

APPENDIX  IV,  MATHEMATICAL  DERIVATIONS  (NEW) 

Note:  n*  = The  next  sequential  number  following  the  number  assigned  to  the  last 
function 


SECTION  50. 


APPENDIX  V,  PROGRAMMING  STANDARDS  (NEW) 


SECTION  60.  APPENDIX  VI,  DESIGN  STANDARDS  (NEW) 


5. 3. 3. 2 Type  C5  Computer  Program  Product  Specification 

The  purpose  of  the  Type  C5  Computer  Program  Product  Specification  is  to  com- 
pletely specify  the  CPCI  to  be  formally  accepted  by  the  Government.  The  critical- 
ity of  a Type  C5  Computer  Program  Product  Specification  is  best  appreciated  by 
recognizing  its  sensitive  role  in  any  follow-on  modification  and  maintenance  of  the 
CPCI.  For  a hardware  Configuration  Item,  the  Type  C5  Product  Specification 
simply  describes  the  Configuration  Item.  For  a software  Configuration  Item,  how- 
ever, the  Type  C5  Product  Specification  actually  is  the  Configuration  Item  in  the 
sense  that  it  is  a one-to-one  reflection  of  the  software  elements  in  the  delivered 
Configuration  Item  and  is  the  prime  instrument  against  which  future  software  modi- 
fications are  measured. 

Two  changes,  and  one  addition  to,  the  Type  C5  Computer  Program  Product  Speci- 
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fication,  as  presented  in  MIL-STD-490  and  MIL-STD-483,  are  planned.  All  the 
information  normally  presented  in  Section  3.3  (Storage  Allocation)  is  presented  in 
the  Data  Base  Specification  instead  (see  Section  5. 3. 3. 3 of  this  report).  Therefore, 
for  completeness,  the  Data  Base  Specification  is  included  by  reference  in  place  of 
the  information  normally  included  in  Section  3.3  of  the  Type  C5  Computer  Program 
Product  Specification.  All  listings  of  the  CPCI  modules  are  included  as  a separate 
appendix  (Section  20)  rather  than  in  Section  3.2.  This  will  make  the  Type  C5 
Computer  Program  Product  Specification  easier  to  use  as  a reference  document 
for  fhture  System  modifications.  The  planned  addition  to  the  Type  C5  Computer 
Program  Product  Specification  is  a special  appendix  (Section  10)  for  detailed 
mathematical  derivations  upon  which  the  design  of  each  Computer  Program  Com- 
ponent in  Section  3.2  is  based. 
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5. 3. 3. 3  Data  Base  Specification 

The  Data  Base  Specification  describes  the  storage  allocation  and  data  base  organi- 
zation and  provides  the  basic  design  data  necessary  for  the  construction  of  the  Sys- 
tem files,  tables,  dictionaries,  and  directories.  This  specification  not  only 
documents  the  data  base  information  needed  to  support  maintenance  efforts  but  also 
represents  the  focal  point  of  data  base  information  for  all  CPC1  contractors.  To 
avoid  duplication  of  effort,  the  Data  Base  Specification  is  included  (by  reference) 
in  Section  3.3  of  all  Type  C5  Computer  Program  Product  Specifications.  The 

only  change  to  the  format  of  the  Data  Base  Specification,  as  defined  in  DoD  Man- 
40 

ual  4120. 17-M,  is  the  replacement  of  the  Common  Data  Pool  with  the  Dictionary 
of  Computer  Variables  in  Section  5.  The  Common  Data  Pool  concept  is  oriented 
principally  to  online  data  base  management  systems  and  hence  is  not  applicable  to 
the  Second  Generation  Comprehensive  Helicopter  Analysis  System.  The  Dictionary 
of  Computer  Variables  provides  crucial  design  and  implementation  data  needed  by 
both  CPC1  contractors  and  System  maintenance  personnel  and  thus  is  best  located 
in  the  Data  Base  Specification. 


DATA  BASE  SPECIFICATION 
Table  of  Contents 
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GENERAL 


1. 1 Purpose  of  the  Data  Base  Specification 

1. 2 Project  References 
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SECTION  2. 


DATA  BASE  IDENTIFICATION  AND  DESCRIPTION 


2. 1 Data  Base  Identification 

2. 1. 1 System  Using  the  Data  Base 
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2. 1. 3 Physical  Description  of  Data  Base  Files 
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2. 3 Organization  of  the  Data  Base 

2.4  Special  Instructions 

2. 5 Support  Programs  Available  for  Handling  the  Data  Base 
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3.1 

Data  Files 

3.2 

Tables 

3.3 

Items 

3.4 

Records  and  Entries 

SECTION 

4. 

DATA  BASE  STORAGE 

4.1 

Internal  Storage  Map  for  the  System 

4.2 

Storage 

SECTION 

5. 

DICTIONARY  OF  COMPUTER  VARIABLES  (NEW) 

5. 3. 3. 4 User's  Manual  , 

1 

The  User's  Manual  provides  the  information  needed  by  System  users  and  com- 
puter operations  personnel.  Sections  1 and  2 of  the  User's  Manual  are  directed  , 

toward  general  management  and  staff  personnel  who  have  limited  need  for  detailed 
technical  information  concerning  System  utilization  or  operation.  Sections  3 and 

4 present  detailed  information  needed  by  engineering  users  who  will  be  using  the  \ 

System  for  performing  helicopter  analysis.  Included  in  Sections  3 and  4 will  be 
instructions  about  providing  input  to  the  System,  about  user  responses  to  System 
requests  for  information,  and  about  the  proper  use/interpretation  of  System  out- 
puts. Section  5 contains  precise,  detailed  information  on  the  operating  procedures 
necessary  to  successfully  initiate,  run,  and  terminate  the  System.  Section  5 is 
directed  toward  supervisory  and  operator  personnel  responsible  for  the  efficient 

performance  of  a computer  facility.  Because  the  System  will  be  operational  on  ■ t,  • 

multiple  computer  families,  Section  5 will  also  contain  operational  information  * 

for  each  Government-specified  host  computer  family. 

The  only  change  in  the  format  of  the  User's  Manual  as  described  in  DoD  Man- 
40 

ual  4120. 17-M  is  the  addition  of  a new  section  (Section  5)  describing  computer 
operation  procedures.  This  new  section  includes  the  information  described  in 
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Section  3.1  (EDP  Operating  Procedures)  and  Section  4 (Non-Routine  Operations)  of 

40 

the  Computer  Operation  Manual  in  DoD  Manual  4120. 17-M.  The  remaining  infor- 
mation in  the  Computer  Operations  Manual  appears  to  be  primarily  oriented  to 
complex  data  entry  and  management  systems  rather  than  to  an  analysis  system. 

It  is  therefore  CSC's  plan  to  eliminate  the  generation  of  a separate  Computer  Op- 
erations Manual.  Instead,  the  necessary  computer  operations  information  will  be 
included  in  the  User's  Manual. 
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FILE  QUERY  PROCEDURES 
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Query  Preparation 
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Operating  Procedures  for  Host  \ 
Computer  Family  1 § 

Equipment  Configuration  I 

Input  Materials  I 

Output  Expected 
Procedures 
Setup 
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Termination 
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5. 3. 3. 5 System  Maintenance  Manual 

The  System  Maintenance  Manual  describes,  for  personnel  responsible  for  adding 
new  capability  and  maintaining  the  System,  the  procedures  necessary  to  effectively 
modify  and  maintain  the  System  software.  The  System /Maintenance  Manual  is  In- 
tended to  supplement  the  Type  B5  Computer  Program  Development  Specification, 
the  Type  C5  Computer  Program  Product  Specification,  and  the  Data  Base  Specifica- 
tion for  use  In  the  future  enhancement  and  maintenance  of  the  System.  The  format 

presented  below  for  the  System  Maintenance  Manual  is  modeled  after  the  format 

40 

presented  In  DoD  Manual  4120. 17-M  for  the  Program  Maintenance  Manual.  The 
differences  between  the  planned  System  Maintenance  and  the  Program  Maintenance 
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Manual  of  DoD  Manual  4120. 17-M  result  from  the  elimination  of  all  duplicate  in- 
formation planned  for  inclusion  in  the  Type  B5  Computer  Program  Development 
Specification  and  the  Type  C5  Computer  Program  Product  Specification.  Sec- 
tions 1.4  (Program  Environment)  and  1.5  (Conventions)  of  the  Program  Mainte- 
nance Manual  have  been  eliminated  because  this  same  information  will  already  have 

r 

been  included  in  the  Type  B5  Computer  Program  Development  Specification. 

Section  2 (System  Description)  has  been  eliminated  because  this  same  informa- 
tion will  already  have  been  presented  in  the  Type  B5  Computer  Program  Devel- 
opment Specification  and  Type  C5  Computer  Program  Product  Specification, 
ection  3 (Input/Output  Descriptions)  has  been  eliminated  because  this  informa- 
tion will  already  have  been  included  in  the  Data  Base  Specification. 

Section  2 (Computer  Independent  Assembling,  Loading,  and  Maintenance  Proce- 
dures) and  Section  3 (Computer  Dependent  Assembling,  Loading,  and  Mainte- 
nance Procedures)  of  the  System  Maintenance  Manual  both  reflect  the  outline 

40 

presented  in  DoD  Manual  4120. 17-M  for  Section  4 (Program  Assembling,  Load- 
ing, and  Maintenance  Procedures)  of  the  Program  Maintenance  Manual,  with  two 
exceptions.  First,  module  listings  will  be  included  in  Appendix  n of  the  Type  C5 
Computer  Program  Product  Specification  rather  than  in  this  document;  second,  a 
new  section  is  added  to  instruct  the  methods  developer  in  the  steps  required  to  add 
new  capability  to  the  System.  The  reason  for  two  sections  of  Assembling,  Load-* 
ing,  and  Maintenance  Procedures  is  a recognition  that  the  System  will  be  opera- 
tional and  must  therefore  be  maintained  on  different  families  of  host  computers. 

Assembling,  loading,  and  maintenance  procedures  will  therefore  vary  among  the  ‘ 

host  computer  families. 
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5 . 3 . 3 . 6 Test  and  Implementation  Plan 

The  Test  and  Implementation  Plan  is  a tool  for  directing  the  integration  and 
acceptance  testing  effort  associated  with  a CPCI.  It  contains  the  schedule  of 
events  and  list  of  materials  necessary  to  effect  delivery  of  the  CPCI  and  to 
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conduct  the  orientation  required  for  proper  use  of  the  CPCI.  Specifically,  this 
plan  has  four  objectives: 


¥ 


1.  To  provide  guidance  for  the  management  and  technical  effort 
necessary  throughout  testing 

2.  To  establish  a comprehensive  test  plan  and  to  communicate  to  the 
Government  the  nature  and  extent  of  the  tests  deemed  necessary 
to  provide  a basis  for  acceptance  of  the  CPCI 

3.  To  provide  an  orderly  schedule  of  events,  a specification  of  equip- 
ment and  organizational  requirements,  the  methodology  of  testing, 
a list  of  materials  to  be  delivered,  and  a schedule  for  Government 
orientation 

4.  To  provide  a written  record  of  actual  test  inputs  used  to  exercise 
CPCI  limits  and  critical  capabilities,  the  instructions  to  permit 
execution  of  the  tests  by  Government  personnel,  and  the  expected 
outputs 

Sections  1,  2,  and  3 will  address  both  integration  testing  and  acceptance  testing 
efforts.  Sections  4 and  5 will  include  the  test  descriptions  and  test  procedures 
for  acceptance  testing.  Test  descriptions  and  test  procedures  for  integration 
testing  will  be  made  available  for  informal  review  upon  request  of  the  Govern- 
ment as  the  material  becomes  available. 

The  only  change  in  the  outline  of  the  Test  and  Implementation  Plan  as  described 

40 

in  DoD  Manual  4120. 17-M  is  the  placement  of  test  evaluation  information.  In 

40 

DoD  Manual  4120. 17-M,  test  evaluation  information  is  presented  in  a separate 
section  (Section  6)  of  the  Test  and  Implementation  Plan  and  is  oriented  to  the  total 
testing  effort.  For  the  Second  Generation  Comprehensive  Helicopter  Analysis 
System,  test  evaluation  Information  is  more  likely  to  be  a function  of  each  test 
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than  a function  of  the  collection  of  all  tests.  Therefore,  test  evaluation  informa- 
tion has  been  added  as  a requirement  to  each  test  procedure  (Section  5). 
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4.1 
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4.1.2 

4.1.3 
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5.1.1 
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5.1. 5. 2 

5. 3. 3. 7 Test  Analysis  Report 

The  Test  Analysis  Report  describes  the  status  of  the  CPCI  after  testing.  This 
document  has  four  objectives: 

1.  To  document  the  results  of  integration  and  acceptance  testing  of 

CPCI  1 > 

2.  To  provide  a basis  for  allocating  responsibility  for  deficiency  correc- 
tion and  followup 

3.  To  provide  a basis  for  the  preparation  of  a Project  completion  state- 
ment 

4.  To  establish  user  confidence  in  the  utilization  of  the  CPCI 
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Two  Test  Analysis  Reports  will  be  produced  for  each  CPCI.  The  first  report 

will  cover  the  integration  testing  effort.  The  second  report  will  cover  the  i 

acceptance  testing  effort.  No  modifications  to  the  outline  of  the  Test  Analysis 

40 

Report  as  described  in  DoD  Manual  4120. 17-M  are  planned. 

r 
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5.3.4  Subordinate  Technical  Plans 

The  first  two  subordinate  technical  plans  presented  in  this  section,  the  Data  Proc- 
essing Facility  Plan  (Section  5.3.4. 1)  and  the  Data  Management  Plan  (Sec- 
tion 5. 3.4. 2),  are  presented,  by  and  large,  intact  from  the  Baseline  Development 
Plan.  The  three  remaining  subordinate  technical  plans,  the  System  Installation 
and  Release  Plan  (Section  5.3.4. 3),  the  Training  Plan  (Section  5.3.4. 4),  and  the 
Maintenance  Plan  (Section  5. 3. 4. 5),  have  been  summarized  from  similarly  titled 
plans  in  the  Baseline  Development  Plan. 
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5.3.4. 1 Data  Processing  Facility  Plan 

This  section  presents  the  computer  facilities  needed  to  support  the  development 
of  the  Second  Generation  Comprehensive  Helicopter  Analysis  System  and  the  data 
processing  facilities  available  through  commercial  vendors  to  support  System 
development.  Mainframe  computer  equipment,  operating  system  software,  pro- 
gramming support  software,  interfacing  terminals,  and  assurance  of  access  to 
CPU  time  are  discussed. 

Because  of  the  desirability  for  all  helicopter  manufacturers  and  Government  users 

to  have  the  System  on  their  computer,  the  Baseline  Type  A System  Specification  | 

has  specified  that  the  System  be  developed  on  the  following  computer  configura- 
tions: the  IBM  S/370  Models  158  and  168  under  OS/VS,  the  IBM  S/360  Model  65 
under  OS/MVT,  and  the  CDC  6600  and  CYBER  series  under  NOS.  To  support  the 

development  of  the  System,  two  development  computers  are  required:  the  Host  1 

. 

Development  Computer  and  the  Host  2 Development  Computer.  The  IBM  S/370 
and  S/360  computers  are  collectively  called  the  Host  1 computer,  and  the 
CDC  6600  and  CYBER  series  computers  are  collectively  called  the  Host  2 com- 
puter. The  Host  1 Development  Computer  configuration  is  a large-scale  IBM 
S/370  (Model  158  or  168)  operating  under  the  Multi-Virtual  Storage  (MVS)  system. 

The  Host  2 Development  Computer  configuration  is  a CDC  CYBER- 175  using  the 
Network  Operating  System  (NOS).  Such  systems  are  available  from  several  com- 
mercial vendors,  who  have  provided  pricing  information  and  assurances  that  their  , 

throughput  capacities  will  be  more  than  ample  to  support  the  projected  require-  \ 

ments  for  development  of  the  System. 

5. 3. 4. 1. 1 Host  1 Development  Computer  Configuration 

The  commercially  available  configuration  proposed  for  use  during  System  develop- 
ment typically  consists  of  one  or  more  IBM  S/370  Model  168  processing  units  of 
core  capacity  equal  to  or  greater  than  5 megabytes  with  all  associated  channeling 
and  controllers  and  a comprehensive  array  of  peripherals.  Total  disk  capacity 
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well  in  excess  of  5000  megabytes  is  common  among  the  vendors.  The  computer 

operating  system,  the  Multi-Virtual  Storage  System,  is  a highly  sophisticated  sys-  i 

tern  that  protects  both  the  Development  Phase  programmer  using  the  Time  Sharing 
Option  (TSO)  and  the  batch  program  from  many  kinds  of  hardware  failure;  offers 
enhanced  security  provisions;  and  supports  the  standard  IBM  languages,  utilities, 

✓ 

and  subsystems.  The  virtual  memory  storage  feature  makes  efficient  use  of  the 
actual  memory,  or  real  storage,  of  the  CPU  by  keeping  program  instructions  and 
data  in  real  storage  only  when  currently  required  for  execution.  The  rest  of  a > 

program  remains  in  external  page  storage,  ready  to  be  "paged  in"  by  the  operating 
system  to  memory  when  needed.  Thus,  an  executing  program  will  "see"  a mem- 
ory capacity  many  times  greater  than  the  actual  CPU  storage. 

The  vendors  interviewed  by  CSC  further  support  their  systems  with  extensive  ! 

object  program  libraries,  macro  libraries,  and  test  and  debug  libraries,  as 
well  as  a large  array  of  programming  languages.  The  IBM  S/370-168  is  inter- 
active to  an  extensive  array  of  TSO  and  graphics  types  of  terminals,  spanning 
a wide  range  of  manufacturers  and  models,  and  may  also  be  accessed  by  both 
remote  job  entry  and  standard  batch  submission.  A remote  job  station,  located 
at  CSC's  Silver  Spring,  Maryland,  facility  providing  remote  batch  and  interactive 
capabilities,  could  be  easily  supported  by  all  the  vendors  surveyed.  To  enhance 
mainframe  accessibility,  a dedicated,  leased- line  system,  with  24-hour  accessi- 
bility, is  also  a standard  offering. 

* r 1 

5.3.4. 1.2  Host  2 Development  Computer  Configuration  ' 

The  commercially  available  computer  facilities  available  to  support  development 
of  the  System  for  the  proposed  Host  2 Development  Computer,  the  CYBER-175, 
typically  consist  of  two  or  more  CYBER-175  central  processor  units,  operating 
under  NOS,  with  real  memory  capacity  of  262,000  60-blt  words.  Each  * 

CYBER-175  is  also  a virtual  storage  computer  having  the  advantages  described 
in  Section  5. 3. 4. 1. 1,  with  up  to  2 million  60-blt  words  of  extended  core  storage. 
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Mainframes  share  a common  permanent  file  system  and  extended  core  storage. 
Furthermore,  the  System  is  supported  by  extensive  object  program  libraries, 
macro  libraries,  test  and  debug  libraries,  and  a large  assortment  of  programming 
languages. 

Interactive  capability  is  available  for  an  extensive  array  of  both  alphanumeric 
and  graphics  types  of  terminals  through  NOS.  These  capabilities  are  also 
accessible  by  remote  job  entry  or  standard  batch  submission.  As  with  the 
Host  1 Development  Computer  configuration,  vendors  of  Host  2 Development 
Computer  services  indicated  that  they  could  easily  support  a remote  job  station 
at  CSC's  Silver  Spring,  Maryland,  facility,  including  both  remote  batch  and  in- 
teractive capabilities.  To  enhance  mainframe  accessibility,  a dedicated, 
leased-line  system,  with  24-hour  accessibility,  is  also  a standard  offering. 

In  addition  to  the  CYBER-175,  access  to  CDC  6000  and  CYBER-70  series  com- 
puters is  provided  by  the  same  vendors  under  the  same  operating  system,  i.  e. , 
NOS. 

5.3.4. 1.3  Terminals 

Vendors  for  both  configurations  of  host  development  computers  support  a wide 
variety  of  terminals.  High-speed,  remote-job-entry  interfaces  with  line  speeds 
up  to  9600  baud  and  the  accompanying  line  printer  and  card  reader /punch  are 
supported,  as  well  as  many  types  of  teletype  or  CRT  graphic  and  interactive 
terminals. 

Upon  contract  award,  CSC  will  determine  the  most  appropriate  hardware, 
which  will  be  acquired  by  lease,  for  establishment  of  a remote  batch  and  inter- 
active station  to  be  dedicated  to  the  development  of  the  System. 

5. 3. 4. 1. 4 Access  to  CPU  and  Turnaround  Time 

Guaranteed  turnaround  time  is  provided  by  commercial  vendors  on  a graduated 
cost  basis.  The  faster  the  turnaround  desired,  the  greater  the  cost,  with 
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interactive  access  being  the  most  expensive.  Of  course,  interactive  processing 
in  many  development  applications  can  also  be  the  most  productive.  The  gradu- 
ation is  effected  through  input  priority  "classes"  requested  by  the  user  when  a 
job  is  submitted  for  processing.  However,  all  of  the  vendors  contacted  expressed 
confidence  that,  because  of  their  present  capacities  and  planned,  near-future  ex- 

j 

pansions,  CSC  would,  on  the  whole,  experience  much  faster  turnaround  time  than 

guaranteed  by  the  priority  class  request.  \ 

5. 3. 4. 1.5  Programmer  Support 

The  software  available  for  programmer  support  through  commercial  service  ven-  1 

dors  is  extensive.  Higher  level  language  compilers  such  as  FORTRAN,  COBOL, 

and  PL/l  are  universally  available,  as  well  as  the  assembly  languages  for  the  , 

respective  host  development  computers.  Services  for  source  program  configura- 
tion control,  code  documentation,  and  performance  testing — all  of  which  greatly 
enhance  the  efficiency  of  the  programmer — are  supported  by  the  vendors  contacted 
by  CSC.  Application  programs  and  systems  spanning  a wide  variety  of  subjects, 
such  as  data  base  management,  structural  analysis,  and  graphics,  are  also  avail- 
able. In  conjunction  with  many  kinds  of  terminals,  the  graphics  software  sup- 
ported by  vendors  can  produce  displays  (interactive  or  hardcopy)  from  the  simplest 
x-y  plot  to  complex  three-dimensional  representations. 

Additionally,  CSC  has  interviewed  several  qualified  minority  contractors  who 
could  provide  card-punch  services  required  during  the  development  effort. 

5. 3. 4. 2 Data  Management  Plan 

* 

f 

To  reduce  risk,  software  and  data  are  stored  in  disk  files  protected  from  acci- 
dental destruction  by  normal  measures — passwords  and  periodic  backup  copies. 

There  are  several  versions  of  the  System  available  for  use.  One  version  is  the  t 

' 

last  completed  build.  (A  build  is  a subset  of  the  System;  see  Section  5.4  for  a dis- 
cussion of  builds. ) This  version  of  the  System  is  maintained  in  a stable  condition 
so  that  it  is  available  for  use  by  the  various  organizations  involved  (e.  g. , CPCI 
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subcontractors).  Other  versions  of  the  System  serve  as  stages  toward  the  comple- 
tion of  the  next  build.  As  CPCIs  are  completed,  they  are  integrated  into  one  of  t ! 

these  versions  of  the  System  and  are  tested  with  the  remainder  of  the  System  being  ^ 

integrated  for  the  next  build.  Procedures  are  applied  to  maintain  libraries  of 
source  modules  from  which  each  version  of  the  System  is  produced  and  to  maintain 

the  various  System  versions  in  executable  form.  I 


A large  amount  of  test  data  is  required  during  System  development.  Initial  versions 
of  the  Master  Data  Base  and  other  files  against  which  tests  are  to  be  run  are  main- 
tained in  association  with  the  input  data  and  the  results  expected  from  the  test. 

Sets  of  test  data  correspond  to  versions  of  the  System.  Associated  with  the  last 
completed  build  in  disk  and  card  files  are  all  tests  run  to  verify  that  build,  and  the 
printed  or  plotted  results  of  those  tests.  Each  version  of  the  System  representing 
a stage  in  the  development  of  a build  has  associated  sets  of  test  data,  including 
valid  data  as  well  as  invalid  data.  The  maintenance  of  the  various  libraries  and 
test  data  files,  their  status,  and  their  associations  is  accomplished  by  establishing 
procedures  for  the  development  of  test  data,  the  integration  of  modules  into  par- 
tially completed  Systems,  the  execution  of  tests,  and  the  recording  of  test  results. 

5. 3. 4. 3 System  Installation  and  Release  Plan 

The  System  Installation  and  Release  Plan  establishes  the  process  to  install  the 
System  on  the  host  computers  specified  by  the  Government  and  to  provide  each 
facility  with  a complete  release  product  set.  A plan  for  the  installation  of  only  the 
First  Level  Release  would  not  be  complete  without  the  inclusion  of  the  installation 
of  the  Second  Level  Release  or  the  provision  for  intermediate  releases  between 
them.  Installation  is  discussed  in  Section  5.3.4. 3. 1,  and  release  is  discussed  in 
Section  5. 3. 4. 3. 2. 

5. 3. 4. 3.1  Installation 

CSC  recommends  that  the  installation  of  the  First  Level  Release  be  done  by 
the  Development  Phase  Contractor  at  each  computer  facility  specified  in  the 
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Development  Phase  contract.  An  installation  is  performed  by  personnel  from 
the  Product  Assurance  Technical  Area  who  generate  the  First  Level  Release 
of  the  System  and  perform  on-site  verification  tests  to  ensure  the  System  is 
functioning  properly.  It  is  recommended  that  Government  personnel,  who  will 
be  responsible  for  System  maintenance  after  the  completion  of  the  Development 
Phase,  be  in  attendance  to  observe  the  techniques  required  to  install  the  System 
on  various  host  computers.  The  reason  for  this  recommendation  is  that  CSC  has 
a supplementary  recommendation  for  the  installation  of  the  Second  Level  Release: 
the  reversal  of  the  roles  of  the  Development  Phase  Contractor  and  Government 
personnel  to  generate  and  install  the  Second  Level  Release  of  the  System.  Specif- 
ically, those  Government  personnel  responsible  for  the  System  maintenance  would 
install  the  System,  with  the  Development  Phase  Contractor  personnel  assisting  in 
a consulting  role  at  the  computer  facilities  specified  in  the  Development  Phase 
contract.  This  approach  provides  Government  personnel  with  an  understanding 
of  the  installation  process  because  they  will  have  been  exposed  to  it  at  First  Level 
Release,  will  have  witnessed  the  System-generation  tasks,  and  will  have  partici- 
pated in  the  discussion  and  resolution  of  problems  that  may  develop  during  the 
event.  Witnessing  the  First  Level  Release  installation  also  assists  in  the  prepa- 
ration of  the  plan  for  the  installation  of  the  Second  Level  Release. 

It  is  also  recommended  that  one  or  two  Intermediate  releases  of  the  System  be 
considered  during  the  first  2 years  of  the  Validation  Phase.  The  purpose  of  an 
intermediate  release  is  to  provide  new  capability  to  the  user  community  and  pro- 
vide corrections  to  the  First  Level  Release.  In  addition  to  enhancing  the  System 
(and  hence  its  acceptance),  an  intermediate  release  can  serve  as  a phase-in  activ- 
ity for  Government  personnel  charged  with  eventual  responsibility  for  mainte- 
nance. Because  the  Development  Phase  Contractor  is  responsible  for  the 
installation  of  the  First  Level  Release  and  presuming  the  Government  Installs  the 
Second  Level  Release  (with  Development  Phase  Contractor  help),  then  a gradual 
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shifting  of  the  roles  between  the  two  levels  provides  for  a smooth  transfer  of 
responsibility. 

5. 3. 4. 3. 2 Release 

A release  product  set  for  the  First  Level  Release  and  the  Second  Level  Release 
of  the  System  contains  complete  documentation,  programmer  installation  instruc- 
tions, tapes,  cards,  listings,  and  any  other  materials  necessary  to  understand, 
use,  operate,  and  maintain  the  System.  Details  on  the  contents  of  the  release 
product  set  can  be  found  in  Section  4. 6. 2 of  the  Baseline  Development  Plan. 

5. 3. 4. 4 Training  Plan 

Training  in  the  System  includes  basic  instruction  for  First  Level  Release  users 
(both  engineering  users  and  methods  developers)  to  introduce  them  to  the  System 
and  advanced  instruction  for  Second  Level  Release  users  who  have  prior  experi- 
ence with  the  System.  CSC  also  strongly  recommends  training  for  programmers 
who  will  install  local  (onsite)  corrections,  aid  methods  developers  in  incorporating 
new  modules  of  the  Technology  Component  in  the  System,  and  eventually  maintain, 
locally,  the  System  for  their  company  or  agency.  Between  the  First  Level  and 
Second  Level  Releases,  it  is  recommended  that  the  Government  consider  review 
training  for  both  new  and  experienced  users  coincident  with  intermediate  releases 
of  the  System. 

The  training  of  users  and  programmers  should  be  scheduled  as  nearly  coincident 
with  the  System  installation  as  possible  to  heighten  the  positive  Impact  of  the  Sys- 
tem. This  recommendation  implies  that  theoretical  concepts  should  be  presented 
before  or  during  installation  and  practical  instruction  should  begin  as  soon  as  the 
System  is  available  at  a facility. 

Thorough  training,  at  the  time  of  each  release,  typically  takes  ,2  weeks  of  instruc- 
tion. The  first  week  Includes  the  mathematical  basis  of  the  System  and  illustra- 
tive examples,  and  the  second  week  is  devoted  to  the  study  of  computer  executions. 
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Training  coincident  with  an  intermediate  release  would  be  for  1 week  because 
this  instruction  is  more  specialized  to  review  current  concepts  and  to  study  new 
developments  introduced  with  the  intermediate  release. 

Two  training  courses  are  recommended:  one  for  users  and  the  other  for  program- 
mers. The  user  training  course  provides  engineering  users  and  methods  devel- 
opers the  knowledge  of  the  capabilities  and  use  of  the  System  to  allow  them  to 
obtain  meaningful  results  from  the  System  and  to  be  able  to  add  to  or  change  soft- 
ware elements  in  the  System.  The  programmer  training  course  introduces  the 
programmer  to  the  software  features  and  requirements  of  the  System.  The  pro- 
grammer's responsibilities  encompass  System  installation.  System  modification, 
aiding  the  methods  developer  in  the  permanent  incorporation  of  new  Technology 
Component  capabilities  into  the  System,  and  understanding  user  requirements. 

Outlines  for  user  courses  and  programmer  courses  are  provided  in  the  Baseline 
Development  Plan. 

It  is  anticipated  that  the  Government  will  play  an  active  management  role  during 
maintenance  activities.  This  role  includes  receiving  from  users  the  description 
of  potential  problems,  providing  the  initial  estimate  of  the  resources  required  to 
incorporate  additions  to  the  System,  and  being  directly  involved  in  determination 
of  what  and  how  information  is  to  be  disseminated  to  users  in  response  to  their 
problems.  To  foster  positive  relationships  with  users  and  programmers,  there 
must  be  a form  of  personnel  assistance  and  consultation  services  available  to 
them. 

It  is  important  to  train  System  users  in  the  Government's  procedures  for  user 
communication  of  information  about  errors  and  about  suggestions  for  incorpora- 
tion of  enhancements.  The  users  must  know  how  the  maintenance  cycle  operates, 
how  the  maintenance  activity  can  be  used  to  assist  them,  and  what  support  ser- 
vices are  available.  To  acquaint  users  and  programmers  with  the  services  avail- 
able to  them,  some  instruction  relative  to  these  services  must  be  included  In  the 
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training  plan  and  should  address  maintenance,  consultation,  and  assistance  serv- 
ices. 

5. 3. 4. 5 Maintenance  Plan 

The  discovery  of  errors  in  the  System  and  timely  correction  of  them  are  of  para- 
mount importance  to  preserve  the  integrity  of  the  System.  Equally  important 
are  the  immediate  assessment  of  the  error  (and  its  impact  on  the  System)  and  the 
determination  of  an  adequate  correction  to  provide  the  user  with  a viable  solution 
to  his  or  her  problem.  Both  of  these  latter  points  involve  response  to  the  user  to 
identify  critical  deficiencies  and  to  incorporate  corrective  action.  Included  with 
the  identification  of  critical  deficiencies  is  the  determination  of  evasive  action  on 
the  part  of  the  user  to  avoid  the  deficiency. 


There  are  several  possibilities  for  disseminating  information  to  users  to  be 
responsive  to  error  conditions  and  corrections.  Examples  are  bulletins  distrib- 
uted to  all  users,  individual  responses  to  users  with  less  critical  problems, 
and  automated  data  bases  intended  for  user  access.  The  first  two  approaches 
are  simple  and  straightforward  forms  of  dissemination  media  but  have  the  in- 
herent disadvantage  of  the  amount  of  distribution  time  required.  The  data  base 
concept  allows  instantaneous  access  to  problems  and  corrections  but  includes 
higher  costs  in  terms  of  maintenance  and  labor.  All  of  these  possibilities  could 
be  utilized  as  complementary  approaches.  Cost  feasibility  and  System  criticality 
dictate  the  "mix.  ” 

Consultation  and  assistance  to  System  users  and  programmers  are  vital  func- 
tions that  must  be  performed  to  ensure  they  obtain  maximum  benefit  from  the 
System.  Direct  personal  relationships  with  the  users  and  programmers  enable 
Development  Phase  Contractor  personnel  to  assess  the  acceptability,  usability, 
and  application  of  the  System  through  personal  communication  and  feedhack. 

The  benefits  derived  are  that  the  Development  Phase  Contractor  can  reevaluate 
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such  important  efforts  as  training  and  documentation  to  clarify  uncertainties  on 
the  part  of  the  users  and  programmers. 

The  Maintenance  Plan  defines  the  approach  and  procedures  to  be  used  for  iden- 
5 tifying  errors  and  deficiencies  in  the  System,  incorporating  additional  modules 

and  CPCIs  into  the  System,  and  disseminating  correction  information  to  users 
during  the  Validation  Phase.  The  Validation  Phase  begins  with  the  First  Level 
Release  of  the  System  and  ends  1 year  after  the  completion  of  the  Development 
Phase.  During  the  Validation  Phase,  the  System  will  be  subjected  to  rigorous 
testing  and  evaluation  by  users  from  industry  and  Government. 

The  maintenance  of  the  System  includes  the  identification  of  errors  and  defi- 
ciencies in  the  System,  the  timely  incorporation  of  corrections  to  errors  and 
deficiencies  as  well  as  the  addition  of  enhancements  and  new  capabilities  to  the 
System,  the  test  and  verification  of  the  System  after  the  incorporation  of  cor- 
rections and  additions,  the  updating  of  System  documentation,  and  the  generation 
and  release  of  an  improved  System. 

To  keep  the  Government/industry  user  community  apprised  of  the  progress  and 
latest  developments  occurring  during  maintenance,  reports  to  the  Government 
by  the  Development  Phase  Contractor  are  required;  dissemination  of  information 
to  the  users  by  the  Government  is  also  required. 

To  keep  the  originator  of  change  requests  and  all  users  (when  required)  apprised 
of  current  maintenance  activities,  dissemination  of  information  is  appropriate  at 
several  steps  in  the  maintenance  cycle.  (The  maintenance  cycle  is  described  in 
* some  detail  in  Section  4. 8 of  the  Baseline  Development  Plan. ) After  the  origina- 

tor has  submitted  a request  to  change  the  System,  the  Government  should  notify 
the  originator  that  the  request  has  been  received  and  an  analysis  of  it  is  in  prog- 
ress. 

During  analysis  of  the  problem,  the  Initial  assessment  of  an  error  with  respect  to 
its  impact  on  the  System  dictates  the  necessity  for  dissemination  of  information 
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to  recognize  that  an  error  exists  and  that  a possible  alternative  (temporary)  solu- 
tion to  evade  the  problem  or  to  utilize  a different  approach  to  achieve  a solution 
equal  to  the  attempted  original  one  is  available.  In  the  event  that  an  apparent 
error  does  not  exist  or  that  the  error  does  exist  and  is  known  by  previous  means, 
the  originator  should  be  informed  of  the  determination.  When  an  error  exists  (for 
which  no  evasion  can  be  identified)  that  is  being  corrected,  all  users  should  be 
made  aware  of  these  conditions. 

When  the  solution  to  the  problem  has  been  verified,  System  modifications  may  be 
disseminated  for  System  updating  at  the  local  site.  This  is  particularly  important 
if  a temporary  solution  to  an  error  could  not  be  identified  during  problem  analysis. 
At  this  time,  enhancements  or  additions  can  be  "advertised"  as  ready  for  general 
use  through  a modification  to  be  made  at  the  local  site. 

Following  the  Government's  acceptance  of  new  or  changed  documentation,  synop- 
sis information  or  full  text  may  be  disseminated,  depending  upon  the  subject  mat- 
ter. Material  related  to  error  corrections  could  be  outlined  in  brief  form, 
whereas  new  capabilities  or  enhancements  would  require  that  full  text  be  available 
to  adequately  derive  full  benefit  from  the  addition  to  the  System. 

The  use  of  the  System  on  different  hardware  configurations  introduces  the 
problem  of  adequate  and  equal  maintenance  on  all  host  computers.  The  effec- 
tiveness of  the  System  requires  the  maintenance  of  both  computer-dependent 
and  computer-independent  software.  Maintenance  of  computer-independent 
software  has  some  impact  on  the  operation  of  the  System  because  the  accept- 
ability of  the  code  on  each  host  computer  must  be  taken  into  account. 

Maintenance  of  computer-dependent  software  is  much  more  inclusive  and  complex: 
overlay  structure,  file  management,  and  module  communications  differences  on 
each  host  computer  require  thorough  integration  and  acceptance  testing  to  ensure 
equal  treatment  for  all  capabilities  of  the  System.  System  utilization  and  load 
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procedures  must  be  evaluated  and  monitored  to  achieve  maximum  efficiency  on 
all  host  computer  families. 

The  Software  Technical  Area  and  the  Product  Assurance  Technical  Area  are 
structured  to  include  specialists  for  each  host  computer  family.  This  approach 
guarantees  concurrent  System  updates  for  each  host  computer.  It  also  ensures 
expert  response  to  System  users'  and  programmers'  questions  as  they  relate  to 
specialized  problems. 

5.4  IMPLEMENTATION  PLAN 

This  Implementation  Plan  establishes  a preliminary  time -phased  plan  for  develop- 
ing the  First  Level  Release  and  the  Second  Level  Release  of  the  Second  Generation 
Comprehensive  Helicopter  Analysis  System.  The  time-phased  plan  presented  in 
this  section  is  based  upon  four  considerations.  First,  the  basic  operational  and 
software  environment,  upon  which  the  overall  System  design  is  based,  will  be 
developed  early  in  the  Development  Phase.  Second,  System  capabilities  will  be 
developed  incrementally  and  integrated  incrementally  into  the  System  throughout 
the  Development  Phase.  Third,  proper  monitoring  by  the  Government  of  the  de- 
velopment effort  calls  for  maximum  visibility.  And  fourth,  acceptance  of  the  Sys- 
tem by  the  helicopter  firms  will  be  enhanced  by  participation  of  the  helicopter 
firms  in  the  System  development  efforts.  Because  of  the  first  two  considerations, 
the  Implementation  Plan  has  been  shaped  by  the  strategy  of  builds,  which  is  a 
powerful,  proven  software  implementation  strategy  that  minimizes  risk.  Because 
of  the  last  two  considerations,  each  functional  capability  of  the  System  has,  for  the 
purposes  of  the  Predesign  Phase,  been  identified  as  a separate  Computer  Program 
Configuration  Item  (CPCI).  The  number  of  CPCIs  to  be  defined  in  the  Development 
Phase  will  be  considerably  fewer  than  the  204  CPCIs  identified  during  the  Prede- 
sign Phase.  Because  of  the  size  and  complexity  of  the  System,  CSC  recommends 
strongly  that  it  be  developed  and  tested  incrementally  in  a series  of  builds  leading 
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to  the  First  Level  Release  capability  and  later  to  the  Second  Level  Release  capa- 
bility. A build,  which  is  a subset  of  the  entire  System,  provides  a demonstrable 
functional  capability  that  is  a subset  of  the  total  functional  capability  of  the  System. 

! This  "build-a-little,  test-a-little"  philosophy  has  several  advantages  over  the  al- 

ternative strategy  of  developing  all  of  the  software  elements  required  to  produce 
‘ the  First  Level  Release  capability  and  then  all  the  software  elements  required  to 

produce  the  Second  Level  Release  capability.  These  advantages  are: 

• Any  major  interface  problems  will  be  discovered  in  the  testing  of  the 
first  or  second  build  when  they  are  more  easily  corrected. 

• The  software  integration  effort,  a source  of  many  problems  in  past 
software  development  efforts,  is  spread  more  smoothly  over  the  entire 
Development  Phase  rather  than  being  placed  near  the  end.  Risk  is 
thus  reduced. 

• A reasonably  stable  and  well-defined  partial  System  is  available  for 
testing  following  the  first  build. 

• A part  of  the  total  System  capability  is  demonstrated  to  the  System’s 
acquirer  and  to  System  users  early. 

To  realize  these  advantages,  the  builds  must  be  judiciously  specified  in  terms  of  r 

functional  capability  and  content.  Each  build  must  have  a demonstrable  functional 
capability  that  is  a subset  of  the  total  System  functional  capability.  A given  build 
contains  all  the  capabilities  of  the  previous  build  plus  new  capabilities.  Capabili- 
ties upon  which  many  parts  of  the  System  are  dependent  (most  Executive  Compo- 
nent capabilities  fall  into  this  category)  are  included  at  an  early  point  in  the  build 
sequence.  Upon  completion  of  a build,  it  is  maintained  in  a stable  condition  for 
use  In  testing  the  elements  of  future  builds. 

During  the  incremental  development  of  the  System,  the  Development  Phase  Con- 
tractor is  responsible  for  integrating  the  CPCIs  into  builds  regardless  of  the 
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organization  responsible  for  the  development  of  the  CPCI  (Development  Phase 
Contractor,  CPCI  subcontractor,  or  Government).  In  each  case,  a preceding 
build,  which  has  been  verified,  is  available  for  module  testing,  CPCI  testing,  in- 
tegration testing,  and  acceptance  testing  by  the  organization  responsible  for  the 
development  of  a CPCI. 

4 

The  Implementation  Plan  is  composed  of  two  subplans:  the  Operational  Complex 
Implementation  Plan  (presented  in  Section  5.4. 1)  and  the  Support  Complex  Imple- 
mentation Plan  (presented  in  Section  5.4.2).  The  Operational  Complex  is  the  part  , 

of  die  System  that  the  engineering  user  accesses  to  obtain  predictions  of  perform- 
ance, stability  and  control,  loads  and  vibrations,  acoustics,  and  aeroelastic 
stability  for  a variety  of  rotary-wing  aircraft  configurations.  The  Support  Com- 
plex is  the  part  of  the  System  that  is  used  to  support  the  development,  testing, 
configuration  control,  and  documentation  of  the  total  System.  Each  complex  is 
composed  of  packages  and  subpackages,  each  of  which  represents  a functional 
capability  of  the  System.  Each  subpackage  of  the  System  has,  for  the  purposes 
of  the  Predesign  Phase,  been  identified  as  a separate  CPCI.  Packages  (that  have 
not  been  subdivided  into  subpackages)  have  also  been  Identified  as  CPCIs.  Because 
each  functional  capability  of  the  System  has  been  identified  as  a separate  CPCI, 
not  only  is  the  Government's  visibility  into  CSC's  plan  for  implementation  in  the 
Development  Phase  maximized,  but  also  the  potential  participation  by  helicopter 
firms  in  the  development  of  System  capabilities  is  maximized. 

Table  10  summarizes  the  detailed  sizing  and  professional  labor  estimates  speci- 
fied in  each  of  the  implementation  subplans.  Eight  builds  (builds  1-8)  have  been 

9 

Identified  for  the  Operational  Complex;  four  builds  (builds  A-D)  have  been  Identi- 
fied for  the  Support  Complex.  Builds  1 to  4 and  A through  D represent  the  First 
Level  Release  on  the  Host  1 computer  family;  build  5 represents  the  First  Level 

» 

Release  on  the  Host  2 computer  family;  and  builds  6,  7,  and  8 represent  the  capa- 
bilities added  to  the  First  Level  Release  for  the  Second  Level  Release. 
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Table  10.  Summary  of  System  Size  and  Professional  Labor  Estimates 


No  estimates  are  indicated  for  Technology  Component  software  in  build  1 because 
build  1 is  planned  to  provide  the  basic  Executive  Component  capabilities  needed  to 
develop  all  subsequent  Operational  Complex  capabilities.  Builds  2 and  3 provide 
the  major  portion  of  the  First  Level  Release  helicopter  analysis  capabilities; 
builds  6 and  7 provide  the  major  portion  of  the  Second  Level  Release  helicopter 
analysis  capabilities  to  be  added  to  the  First  Level  Release.  Builds  4 and  8 are 
intentionally  planned  to  be  relatively  small  builds  because  each  represents  the  last 
build  in  an  operational  release  of  the  System  and  will  therefore  require  acceptance- 
level  testing  in  addition  to  integration  testing.  In  addition,  problems  or  inconsis- 
tencies discovered  in  prior  builds  can  be  corrected  in  these  two  small  builds  with 
the  least  potential  impact  on  the  development  schedule.  Another  special  build  is 
build  5.  Because  this  build  provides  the  First  Level  Release  capabilities  on  the 
Host  2 computer  family,  only  the  Executive  Component  is  affected.  No  Technology 
Component  size  and  labor  estimates  are  supplied  for  build  5 because  no  Technology 
Component  software  will  be  affected  by  this  extension  of  the  System  to  the  Host  2 
computer  family. 

The  number  of  lines  of  executable  code  for  the  Second  Level  Release  of  the  System 
is  estimated  at  136,550  and  the  professional  labor  for  development  of  this  capa- 
bility is  estimated  at  966.5  man-months  (80.5  man-years). 

Each  of  the  two  implementation  subplans  is  presented  in  the  form  of  a development 
schedule  for  each  complex  and  a sequence  of  build  tables.  The  development  sched- 
ules Identify  the  major  development  activities  required  to  develop  the  First  Level 
and  Second  Level  Releases,  and  show  the  time-phased  plan  for  the  development  of 
each  build  in  each  Complex.  For  each  build,  a summary  description  of  the  opera- 
tional capabilities  (functions)  provided  by  the  build  is  presented  at  the  beginning  of 
each  table.  Each  build  is  identified  in  terms  of  the  packages  or  subpackages  to  be 
included  in  It.  In  addition,  the  packages  and  subpackages  in  each  build  are  pre- 
sented in  the  hierarchical  framework  of  the  System  so  that  the  functional  relation- 
ships can  be  understood. 


For  each  software  element  of  the  build,  four  factors  are  identified  which  provide 
information  essential  to  planning  and  control.  These  four  factors  are:  Estimated 
Lines  of  Code,  Estimated  Development  Labor  (Man-Months),  Estimated  Memory 
Requirements  (Bytes),  and  Candidate  CPCI  Source.  These  four  factors  are  pre- 
sented in  four  columns  for  each  build.  The  Estimated  Lines  of  Code  column  of 
the  build  tables  is  an  estimate  of  the  number  of  executable  FORTRAN  statements 
to  be  included  in  each  software  element.  The  Estimated  Development  Labor 
column  in  each  build  table  represents  the  estimated  professional  man-months 
needed  to  develop  the  software  element.  The  labor  estimates  include  all  the 
development  activities  (i.e. , analysis,  design,  code,  test,  documentation,  train- 
ing, etc.)  required  by  the  organization  responsible  for  the  development  of  the  soft- 
ware element. 

The  Estimated  Memory  Requirements  column  of  the  build  tables  represents  an 
estimate  of  the  number  of  bytes  of  memory  required  on  an  IBM  S/370  (or  S/360) 
computer.  These  estimates  represent  the  total  memory  required  for  both  instruc- 
tion storage  and  local  data  storage.  While  data  storage  was  estimated  as  a func- 
tion of  capability,  instruction  storage  estimates  were  based  on  an  average  of  either 
six  computer  instructions  (each  requiring  an  average  of  four  bytes)  per  executable 
FORTRAN  statement  for  highly  computational  software  elements  or  four  computer 
instructions  per  executable  FORTRAN  statement  for  all  other  software  elements. 

The  last  column  of  each  build  table  (Candidate  Software  Source)  identifies  a poten- 
tial source  of  the  software  element.  While  it  is  theoretically  possible  that  each 
software  element  could  be  provided  by  independent  contractors,  the  resulting  costs 
and  risks  associated  with  this  approach  are  unacceptable.  The  approach  selected 
was  to  Identify  common  potential  sources  for  groups  of  software  elements  so  that 
development  can  proceed  in  parallel  and  independently.  This  approach  minimizes 
the  impact  that  one  development  effort  can  have  on  a parallel  development  effort. 

In  addition,  two  assumptions  affected  the  identification  of  candidate  software 
sources:  (1)  few,  if  any,  of  the  software  elements  planned  for  inclusion  in  the 
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First  Level  System  Release  would  be  Government  furnished,  and  (2)  few,  if  any, 
of  the  software  elements  planned  for  inclusion  in  the  Second  Level  System  Release 
would  be  furnished  by  subcontractors. 

5.4.1  Implementation  Plan  for  the  Operational  Complex 

Eight  builds  are  planned  for  the  Operational  Complex.  The  first  build  establishes 
a basic  operational  and  software  environment  so  that  subsequent  development  ef- 
forts can  proceed  in  parallel.  Builds  2,  3,  and  4 provide  capabilities  required  in 
the  First  Level  System  Release.  Build  4 is  the  equivalent  to  the  First  Level 
Release  capability  on  the  Host  1 computer  family,  i.  e. , the  IBM  360/370  computer 
family.  Build  5 is  the  equivalent  of  the  First  Level  Release  capability  on  the 
Host  2 computer  family,  i.e. , the  CDC  6000/CYBER  computer  family.  Builds  6, 
7,  and  8 provide  the  added  capabilities  required  in  the  Second  Level  Release. 

Build  8 is  the  equivalent  to  the  Second  Level  Release  capability  on  both  the  Host  1 
and  Host  2 computer  families. 

Figure  40  presents  the  planned  schedule  for  developing  the  First  and  Second  Level 
Releases  of  the  Operational  Complex.  The  schedule  indicates  that  the  First  Level 
Release  will  be  available  for  Government  acceptance  testing  midway  through  the 
four-year  Development  Phase.  It  is  expected  that  the  First  Level  Release  will  be 
ready  for  installation  on  Government- specified  IBM  S/370  and  S/360  computers 
throughout  the  helicopter  analysis  community  3 months  after  initiation  of  Govern- 
ment acceptance  testing.  The  Second  Level  Release  of  the  Operational  Complex 
will  be  available  for  Government  acceptance  testing  3 months  before  the  end  of  the 
Development  Phase.  The  Second  Level  Release  will  be  ready  for  Installation  on 
Government-specified  IBM  360/370  computers  and  CDC  6000/CYBER  computers 
throughout  the  helicopter  analysis  community  by  the  end  of  the  fourth  year  in  the 
Development  Phase. 

The  15  milestone  events  presented  in  Figure  40  provide  the  visibility  needed  by 
the  Government  to  assess  the  progress  of  the  Development  Phase,  to  verify  that 
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Figure  40.  Milestone  Schedule  for  Development  of  the  Operational  Complex 
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each  release  of  the  System  provides  an  effective  helicopter  analysis  capability, 
and  to  ensure  that  the  requirements  identified  in  the  Type  A System  Specification 
are  satisfied  by  the  System.  The  schedule  has  two  special  characteristics  which 
ensure  this  visibility:  (1)  most  events  are  scheduled  to  occur  at  least  once  for 
each  formal  System  release  - this  ensures  the  same  visibility  into  both  the  First 
Level  Release  and  the  Second  Level  Release  development  efforts;  (2)  intermediate 
releases  (builds)  of  each  formal  release  will  be  provided  for  Government  use  to 
permit  the  Government  to  evaluate  progress  based  upon  actual  hands-on  use  of  the 
System. 

Three  quarters  (9  months)  are  scheduled  for  the  generation  of  the  Type  B5  Devel- 
opment Specifications  for  each  formal  System  release.  Each  schedule  includes 
not  only  the  actual  generation  of  the  Type  B5  Development  Specifications  (event  1) 
but  also  an  early  review  of  the  technical  direction  being  pursued  by  the  Develop- 
ment Phase  Contractor  (event  2 - Functional  Design  Review),  the  final  specifica- 
tion of  the  capabilities  to  be  provided  by  each  build  (event  3),  and  the  detailed 
reviews  which  culminate  in  the  Government's  formal  concurrence  on  a baseline 
Type  B5  Development  Specification  (event  4). 

Based  upon  Section  4,  Quality  Assurance  Provisions,  of  the  baseline  Type  B5 
Development  Specification  for  each  release,  an  integration  and  acceptance  test 
plan  is  generated  by  the  Development  Phase  Contractor  (event  5)  and  submitted 
to  the  Government  for  concurrence  (event  6). 

i 

The  development  of  the  Type  C5  Product  Specifications  (event  7)  for  each  System 
release  begins  when  the  corresponding  Type  B5  Development  Specification  is  ' 

baselined  (event  6)  and  continues  throughout  the  Development  Phase.  The  Type  C5 
Product  Specification  for  each  release  is  baselined  (event  10)  when  acceptance 
testing  (Formal  Qualification  Testing)  for  the  release  begins.  Two  types  of  for- 
mal reviews  are  scheduled  while  the  Type  C5  Product  Specification  for  each  re- 
lease is  being  developed:  a Preliminary  Design  Review  (PDR)  and  three  Critical 
Design  Reviews  (CDRs). 
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The  PDR  for  each  release  (event  8)  is  scheduled  to  occur  within  3 months  after 
preparations  begin  on  the  corresponding  Type  C5  Product  Specification.  These 
two  PDRs  provide  a positive  demonstration  that  the  detailed  design  of  each  release 
is  proceeding  efficiently.  Each  CDR  provides  a formal  opportunity  for  the  Govern- 
ment to  determine  whether  the  functional  requirements  of  the  Type  B5  Develop- 
ment Specification  are  being  met  by  the  detailed  System  design,  if  there  is  an 
integrated  design  with  closure,  and  if  the  cost  and  risk  factors  are  reasonable. 
Acceptance  testing  specifications  and  procedures  representing  the  subset  of  Sys- 
tem capabilities  provided  by  each  build  will  also  be  reviewed  at  each  CDR. 

Three  CDRs  are  planned  for  each  System  release  (event  9).  Each  CDR  is  planned 
to  cover  all  the  software  in  either  one  or  two  complete  builds.  For  the  First 
Level  Release,  the  first  CDR  will  cover  the  first  two  builds  (these  two  builds  are 
reviewed  together  because  they  form  the  nucleus  of  the  System);  the  second  CDR 
will  cover  build  3;  and  the  third  CDR  will  cover  builds  4 and  5.  For  the  Second 
Level  Release,  each  of  the  three  scheduled  CDRs  will  cover  one  of  the  remaining 
three  builds  (6,  7,  and  8). 

Implementation  and  testing  of  each  release  will  be  done  incrementally  (event  11). 
Four  builds  are  planned  for  the  First  Level  Release.  The  fifth  build  is  a special 
build  which  will  provide  all  First  Level  Release  capabilities  on  CDC  6000/CYBER 
computers.  Three  builds  (builds  6,  7,  8)  are  planned  for  the  Second  Level  Re- 
lease. As  each  build  is  completed  (i.e. , coding,  documentation,  integration  test- 
ing), the  corresponding  version  of  the  System  will  be  made  available  to  the 
Government  for  experimental  use  so  that  the  Government  can  both  gain  early 
familiarity  with  the  characteristics  and  potential  of  the  System  and  evaluate  the 
progress  based  on  actual  use  of  the  System. 

At  the  conclusion  of  implementation  and  integration  testing  of  the  last  build  in  each 
release  (build  4 for  the  First  Level  Release  and  build  8 for  the  Second  Level  Re- 
lease), acceptance  testing  Is  scheduled  to  commence  (event  12).  Immediately  after 
acceptance  testing  Is  completed  for  each  release,  a Physical  Configuration  Audit 


(PC  A)  is  conducted  (event  13).  During  the  PC  A,  all  documentation  produced  for 
the  System  release  being  audited  is  reviewed  by  the  Government  to  ensure  its 
completeness  and  accuracy.  Following  Government  acceptance  of  the  Acceptance 
Testing  Report  (event  14)  and  all  the  documentation  pertaining  to  the  System  re- 
lease (event  15),  the  release  will  be  installed  on  all  Government-specified  host 
computers  for  validation  by  the  helicopter  analysis  community. 

Table  11  indicates  which  build  contains  the  capabilities  needed  to  analyze  the  five 
technical  characteristics  (performance,  stability  and  control,  loads  and  vibrations, 
acoustics,  aeroelastlc  stability)  for  each  of  the  three  life  cycle  phases  (preliminary 
design,  detailed  design,  research)  identified  in  the  Baseline  Type  A System 
Specification.  The  loads  and  vibrations  analysis  capability,  however,  is  presented 
in  terms  of  four  categories  (rotor  loads,  airframe  loads,  engine/drive  system 
loads,  and  control-system/pilot  loads)  to  show  how  the  total  loads  and  vibrations 
analysis  capability  evolves. 

Figure  41  represents  a model  schedule  for  the  development  of  a CPCI,  starting 
with  the  generation  of  the  necessary  Type  C5  Product  Specifications.  Hie  actual 
amount  of  time  required  to  develop  a CPCI  will  vary  depending  upon  the  size  and 
complexity  of  the  CPCI.  The  relative  time  required  for  each  CPCI  development 
activity  is  expected  to  correlate  closely  with  the  relative  times  indicated  in  the 
model  schedule.  A detailed  schedule  for  each  specific  CPCI  will  be  produced  by 
the  contractor  or  subcontractor  responsible  for  the  development  of  the  CPCI. 

Tables  12  through  19  present  the  plan  for  implementing  the  software  elements  of 
the  Operational  Complex  identified  in  the  Predesign  Phase.  Each  tflhla  corre- 
sponds to  one  of  the  eight  builds  of  the  Operational  Complex.  The  software  ele- 
ments in  each  build  table  are  presented  in  the  hierarchical  framework  of  the 
Operational  Complex  so  that  functional  relationships  can  be  understood.  In  each 
build  table,  software  elements  which  are  directly  related  to  helicopter  analysis 
(i.  e. , the  Technology  Component)  are  listed  ahead  of  those  which  are  related  to 
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Table  11.  Build  Sequence  for  Achievement  of  Aircraft  Technical 
Characteristic  and  Life-Cycle  Phase  Analysis 
Capabilities 


LIFE-CYCLE  PHA8E 

TECHNICAL  ' 

CHARACTERISTICS  " — ■ 

PRELIMINARY 

DESIGN 

DETAILED 

DESIGN 

RESEARCH 

PERFORMANCE 

2 

4 

7 

STABILITY  AND  CONTROL 

3 

3 

7 

LOADS  AND  VIBRATIONS 

ROTOR  LOADS 

3 

3 

7 

AIRFRAME  LOADS 

6 

7 

7 

ENGINE/DRIVE  SYSTEM  LOADS 

6 

7 

7 

CONTROL-SYSTEM/PILOT  LOADS 

6 

7 

8 

ACOUSTICS 

4 

6 

6 

AEROELASTIC  STABILITY 

4 

4 

7 

Table  12.  Build  1 of  the  Operational  Complex  (1  of  2) 


FUNCTIONS: 

1.  Process  a rudimentary  set  of  user  input  (Case  Specification  Section) 

2.  Construct  and  use  a limited  Sequence  Control  Table  and  a limited 
Run  Data  Base 

3.  Execute  dummy  Technology  Component  software  elements 

4.  Identify  the  software  elements  to  be  executed 

5.  Print  user  output  in  a single  format 

6.  Provide  computer-independent  file  management,  program  man- 
agement, and  storage  management  support  services 

7.  Provide  computer-independent  cost  assessment  and  diagnostic 
support  services 


CONTENTS: 


1 — — 

CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHSI 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

EXECUTIVE  COMPONENT 

1 

USER  INTERFACE  SUBSYSTEM 

1. 

User  Input  Subpackage  I 

1000 

- ■ 

2 OK 

DPC 

2. 

User  Output  Subpackage  I 

1000 

7. 5 

2 OK 

DPC 

RUN- 

-TIME  MANAGEMENT  SUBSYSTEM 

1. 

Sequence  Control  Subpackage  I 

100 

0.5 

2K 

DPC 

2. 

Run-Time  Control  Package 

1000 

5.5 

20K 

DPC 

DATA  BASE  MANAGEMENT  SUBSYSTEM 

1. 

Data  Storage  Subpackage  I 

2000 

15.0 

4 OK 

DPC 

2. 

Data  Retrieval  Subpackage  I 

2000 

15.0 

40K 

DPC 

’OPC  • DEVELOPMENT  PHASE  CONTRACTOR  WITH  INTEGRATED  TEAM 
MEMBER  SUBCONTRACTOR 

CS  - CPCI  SUBCONTRACTOR 
GF  • GOVERNMENT  FURNISHED 
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Table  12.  Build  1 of  the  Operational  Complex  (2  of  2) 

CONTENTS:  l 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

OPERATING  SYSTEM  SERVICE 
SUBSYSTEM 

1.  Host  1 File  Management  Subpack- 

1000 

7.5 

20K 

DPC 

2. 

age 

Host  1 Program  Management 

1000 

7.5 

2 OK 

DPC 

3. 

Subpackage 

Host  1 Storage  Management  Sub- 

1000 

7.5 

2 OK 

DPC 

4. 

package 

Host  1 Cost  Assessment  and 

1000 

5.5 

20K 

DPC 

Diagnostic  Services  Subpackage 

TOTAL 

11100 

79.0 

Table  13.  Build  2 of  the  Operational  Complex  (1  of  4) 


ADDED  FUNCTIONS: 


1.  Perform  Preliminary  Design  Performance  Analysis  (steady- 
state  and  transient) 

2.  Provide  all  the  general  mathematical  capabilities  needed  to 
perform  a steady-state  and  a-  transient  Preliminary  Design 
Performance  Analysis 

3.  Process  an  expanded  set  of  user  input  (Configuration  Specifica- 
tion Section  and  Conditions  Specification  Section) 

4.  Allow  the  specification  of  all  possible  System  Commands 
except  for  those  required  for  restarting  an  analysis  run 

5.  Create  the  Run  Data  Base  from  the  Master  Data  Base  and 
from  user  input 

6.  Provide  multiple  output  report  formats 

7.  Provide  System  status  information  whenever  a potential 
internal  System  software  error  is  detected 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

TECHNOLOGY  COMPONENT 

SIMULATION  MODEL  INITIALIZATION 
SUBSYSTEM 

1. 

Combine  Aircraft  Components 
Package 

500 

3.0 

18K 

DPC 

2. 

Combine  Environment  Compo- 
nents Package 

500 

3.0 

18K 

DPC 

3. 

Combine  Aircraft  and  Environ- 
ment Components  Package 

500 

3.0 

18K 

DPC 

4. 

Coordinate  Systems  and  Trans- 
formations Package 


250 

— 

1.5 



10K 



DPC 

’oPC  - DEVELOPMENT  PHASE  CONTRACTOR  WITH  INTEGRATED  TEAM 
MEMBER  SUBCONTRACTOR 

CS  - CPCI  SUBCONTRACTOR 
OF  - GOVERNMENT  FURNISHED 
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Table  13.  Guild  2 of  the  Operational  Complex  (2  of  4) 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS! 

ESTIMATEO 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

SIMULATION  MODEL  SUBSYSTEM 

1. 

Rigid  Blade  Rotor  Subpackage 

400 

2.5 

12K 

DPC 

2. 

Steady  Aerodynamic  Field  for 
a Rotor  Subpackage 

150 

1.0 

5K 

DPC 

3. 

Standard  Helicopter  Rigid  Con- 
trol System  Subpackage 

100 

0.5 

3K 

DPC 

4. 

Rigid  Drive  System/Conetant 
Speed  Analysis  Subpackage 

150 

1.0 

5K 

DPC 

5. 

Engine  Performance  Table  Sub- 
package 

200 

1.0 

6K 

DPC 

6. 

Rigid  Two-Dimensional  Fuse- 
lage Subpackage 

200 

1.0 

6K 

DPC 

7. 

Rigid  Three-Dimensional  Fuse- 
lage Subpackage 

200 

1.0 

6K 

DPC 

8. 

Aerodynamic  Field  for  an  Aero- 
dynamic Surface  Subpackage 

150 

1.0 

-»l. 

5K 

DPC 

9. 

Rigid  Aerodynamic  Surface 
Subpackage 

100 

0.5 

3K 

DPC 

10. 

Rigid  Stores  Subpackage 

200 

1.0 

6K 

DPC 

11. 

Steady  Aerodynamic  Coefficients 
Using  Simple  Equations  Sub- 
package 

100 

1.0 

3K 

DPC 

12. 

Steady  Aerodynamic  Coefficients 
Using  Bivariant  Table  Sub- 
package 

50 

0.5 

2K 

DPC 

13. 

Steady  Aerodynamic  Coefficients 
Using  Trivariant  Table  Sub- 
package 

100 

0.5 

3K 

DPC 

14. 

Steady  Aerodynamic  Coefficients 
Using  Quadrivariant  Table  Sub- 
package 

150 

1.0 

5K 

DPC 

15. 

Momentum  Theory  Flow  Field 
Subpackage 

150 

6K 

CS 

16. 

Momentum  Theory  Flow  Field 
With  Time  Delay  Subpackage 

300 

n 

UK 

CS 
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Table  13 


Build  2 of  the  Operational  Complex  (3  of  4) 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHSI 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE’ 

TRIM  SOLUTION  SUBSYSTEM 

1.  Simultaneous  Iterate- to-Trim 

1000 

7.5 

30K 

DP  C 

Subpackage 

MANEUVER  SUBSYSTEM 

1.  Prescribed  Control  Motions 

300 

1.5 

10K 

DPC 

Package 

2.  Prescribed  Aircraft  Response 

400 

3.0 

12K 

DPC 

Package 

GENERAL  MATHEMATICAL 
OPERATIONS  SUBSYSTEM 

1.  Linear  Algebraic  Equation  Solu- 

800 

4.5 

30K 

DPC 

tion  Package 

2.  Matrix  Decomposition  Package 

600 

3.5 

25K 

DPC 

3.  Differential  Equation  Solution 

1000 

5.5 

40K 

DPC 

Package 

4.  Quadrature  Package 

200 

1.0 

8K 

DPC 

5.  Matrix  Multiplication  and  Addi- 

500 

3.0 

20K 

DPC 

tion  Package 

6.  Nonlinear  Algebraic  Equation 

600 

3.5 

25K 

DPC 

Solution  Package 

7.  General  Coordinate  Transforma- 

100 

0.5 

4K 

DPC 

tion  Package 

8.  Numerical  Differentiation  Pack- 

600 

3.5 

25K 

DPC 

• 

age 

9.  Interpolation/Extrapolation 

400 

2.5 

15K 

DPC 

Package 

10.  Harmonic  Analysis  Package 

400 

2.5 

15K 

DPC 

♦ 

EXECUTIVE  COMPONENT 

USER  INTERFACE  SUBSYSTEM 

1.  User  Input  Subpackage  II 

2000 

15.0 

40K 

DPC 

2.  User  Output  Subpackage  II 

1000 

7.5 

20K 

DPC 
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Table  13.  Build  2 of  the  Operational  Complex  (4  of  4) 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE’ 

RUN-TIME  MANAGEMENT  SUBSYSTEM 

1. 

Sequence  Control  Subpackage  II 

100 

0.5 

2K 

DPC 

2. 

Internal  System  Error  Analysis 
Package 

1000 

7.5 

20K 

DPC 

DATA  BASE  MANAGEMENT 
SUBSYSTEM 

1. 

Data  Storage  Subpackage  II 

1000 

5.5 

20K 

DPC 

2. 

Data  Retrieval  Subpackage  II 

1000 

5.5 

20K 

DPC 

TOTAL 

17450 

110.0 

I 

I 

t 

\ 

V 

r 

Table  14.  Build  3 of  the  Operational  Complex  ( 1 of  3) 


ADDED  FUNCTIONS: 


1.  Perform  Preliminary  Design  Stability  and  Control  Analysis 

2.  Perform  Preliminary  Design  Rotor  Loads  Analysis 

3.  Perform  Detailed  Design  Rotor  Loads  Analysis 

4.  Perform  Detailed  Design  Stability  and  Control  Analysis 

5.  Allow  the  specification  of  unsteady  airloads 

6.  Permit  the  definition  of  moveable  control  surfaces 

7.  Solve  the  eigenproblem  (eigenvalues  and  eigenvectors) 

8.  Process  the  Options  Specification  Section  of  user  input 

9.  Restart  an  analysis  run 

10.  Allow  the  specification  of  all  possible  System  Commands 

11.  Generate  a plot  in  a single  format 

12.  Generate  a cost  assessment  report  at  run  conclusion 

13.  Maintain  and  use  a partially  core- resident  Run  Data  Base 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
COOE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

TECHNOLOGY  COMPONENT 

SIMULATION  MODEL  INITIALIZATION 
SUBSYSTEM 

1.  Rotor  Finite  Element  Initialization 
Package 

300 

1.5 

9K 

CS 

2.  Rotor  Modes  Package 

SIMULATION  MODEL  SUBSYSTEM 

500 

3.0 

15K 

CS 

1.  Rotor  Map  Subpackage 

200 

1.0 

6K 

DPC 

2.  Semi-Empirical  Rotor  Equations 
Sutapackage 

250 

1.5 

9K 

DPC 

3.  Semi-Empirical  Directed  Fan 
Subpackage 

250 

2.0 

9K 

CS 

’dpc  - 

DEVELOPMENT  PHASE  CONTRACTOR  WITH  INTEGRATED  TEAM 

MEMBER  SUBCONTRACTOR 

CS  - 

CPCI  SUBCONTRACTOR 

1 

OF  - 

GOVERNMENT  FURNISHED 
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Table  14.  Build  3 of  the  Operational  Complex  (2  of  3) 


I 

)' 

t 

» 

l 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
COOE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHSI 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE’ 

SIMULATION  MODEL  SUBSYSTEM 
(Continued) 

4.  Dynamic  Blade  Rotor  With  Teeter- 

1000 

■ 

30K 

GF 

5. 

ing  Gimbaled  Hub  Subpackage 
Dynamic  Blade  Rotor  With  Artie- 

1000 

H 

30K 

GF 

6. 

ulated  Hub  Subpackage 

Dynamic  Blade  Rotor  With 

1000 

H 

30K 

GF 

7. 

Hingeless  Hub  Subpackage 

Dynamic  Blade  Rotor  With  Bear- 

1000 

30K 

GF 

8. 

ingless  Hub  Subpackage 

Rotor  Loads  and  Vibrations 

800 

6.0 

24K 

DPC 

9. 

Subpackage 

Unsteady  Aerodynamic  Field  For 

100 

0.5 

3K 

CS 

10. 

a Rotor  Subpackage 

Viscous  or  Hydraulic  Lag 

150 

1.0 

5K 

DPC 

11. 

Damper  Subpackage 

Elastomeric  Lag  Damper 

150 

1.0 

5K 

DPC 

12. 

Subpackage 

Rotor  Flapping  Stops  Subpackage 

150 

1.0 

5K 

DPC 

13. 

Rotor  Lag  Stops  Subpackage 

150 

1.0 

5K 

DPC 

14. 

Auxiliary  Controls  Subpackage 

200 

1.0 

6K 

DPC 

15. 

Rigid  Pylon  Subpackage 

200 

1.0 

6K 

DPC 

16. 

Simple  Landing  Gear  Subpackage 

500 

3.0 

15K 

DPC 

17. 

Internal  Cargo  Subpackage 

100 

0.5 

3K 

DPC 

18. 

Unsteady  Airloads  by 

300 

2.0 

9K 

CS 

19. 

Theodor  sen/ Loe wy  Theory  Sub- 
package 

Unsteady  Airloads  by  a.  A, 

400 

3.0 

12K 

CS 

20. 

B Table  Subpackage 

Flap  Aerodynamic  Coefficients 

250 

1.5 

9K 

DPC 

21. 

Subpackage 

Spoiler  Aerodynamic  Coefficients 

150 

1.0 

6K 

DPC 

22. 

Subpackage 

Structural  Coupling  Package 

15.0 

60K 

DPC 
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Table  14.  Build  3 of  the  Operational  Complex  (3  of  3) 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

STABILITY  AND  CONTROL  SUBSYSTEM 

1.  Linearize  Equations  for  Stability 

500 

3.0 

25K 

DPC 

and  Control  Package 

2.  Stability  Eigenvalues  and  Eigen- 

250 

1.5 

13K 

DPC 

\ 

vectors  Package 

3.  Transfer  Functions  and  Fre- 

250 

1.5 

13K 

DPC 

quency  Response  Package 

i 

GENERAL  MATHEMATICAL 

! 

OPERATIONS  SUBSYSTEM 

1.  Eigenvalue/Eigenvector  Pack- 

1200 

7.0 

60K 

DPC 

age 

EXECUTIVE  COMPONENT 

USER  INTERFACE  SUBSYSTEM 

1.  User  Input  Subpackage  in 

1000 

7.5 

2 OK 

DPC 

2.  User  Output  Subpackage  III 

1000 

7.5 

2 OK 

DPC 

RUN-TIME  MANAGEMENT  SUBSYSTEM 

1 

> 

\ 

1.  Sequence  Control  Subpackage  III 

100 

0.5 

2K 

DPC 

2.  Checkpoint  Package 

1000 

5.5 

20K 

DPC 

' 

DATA  BASE  MANAGEMENT 

SUBSYSTEM 

1 

1.  Data  Storage  Subpackage  III 

11.5 

40K 

DPC 

2.  Data  Retrieval  Subpackage  in 

11.5 

40K 

DPC 

TOTAL 

20400 

134.5 

1 
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Table  15.  Build  4*  of  the  Operational  Complex  (1  of  3) 

ADDED  FUNCTIONS: 


1.  Perform  Preliminary  Design  Acoustics  Analysis 

2.  Perform  Preliminary  Design  Aeroelastic  Stability  Analysis 

3.  Perform  Detailed  Design  Performance  Analysis 

4.  Perform  Detailed  Design  Aeroelastic  Stability  Analysis 

5.  Perform  an  analysis  of  moving  deck  (on  a ship  or  in  ground 
contact)  operations 

6.  Provide  an  alternative  trim  procedure 

7.  Provide  a generalized  control  system  model 

8.  Provide  a whirl/test  stand  model 

9.  Perform  wake  analysis 

10.  Provide  an  interface  for  external  models 

11.  Complete  the  set  of  general  mathematical  operations 

12.  Process  the  Failure/Damage  Specification  Section  of  user  input 

13.  Include  a description  of  failure/damage  effects  in  the  Run  Data 
Base  (from  user  input  and  the  Master  Data  Base) 

14.  Generate  plots  in  multiple  formats 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
COOE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

TECHNOLOGY  COMPONENT 

SIMULATION  MODEL  INITIALIZATION 
SUBSYSTEM 

1.  Wake  Initialization  Package 

SIMULATION  MODEL  SUBSYSTEM 

100 

0.5 

4K 

GF 

1.  Generalized  Coupling  Rigid 

Control  System  Subpackage 

200 

1.0 

6K 

DPC 

2.  Static  Elastic  Driveshaft 

Subpackage 

100 

0.5 

3K 

DPC 

*BUILO  4 IS  EQUIVALENT  TO  THE  FIRST  LEVEL  RELEASE  CAPABILITY  OPERATING  ON  A HOST  1 COMPUTER. 


’oPC  - DEVELOPMENT  PHASE  CONTRACTOR  WITH  INTEGRATED  TEAM 
MEMBER  SUBCONTRACTOR 

CS  CPCI  SUBCONTRACTOR 
GF  - GOVERNMENT  FURNISHED 


Table  15.  Build  4*  of  the  Operational  Complex  (2  of  3) 


I 

\ 

t 

i 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
COOE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE’ 

SIMULATION  MODEL  SUBSYSTEM 
(Continued) 

3.  Prescribed  Motion  Test  Stand 

Subpackage 

200 

1.0 

6K 

DPC 

4.  Prescribed  Wake  Subpackage 

1500 

8.5 

55K 

GF 

5.  Prescribed  Motion  Ground/ 

Deck  Surface  Subpackage 

150 

1.0 

6K 

DPC 

6.  Two-Dimensional  Ground/Deck 

Surface  Subpackage 

100 

0.5 

4K 

DPC 

7.  Three-Dimensional  Ground/ 

Deck  Surface  Subpackage 

TRIM  SOLUTION  SUBSYSTEM 

200 

1.0 

8K 

DPC 

1.  Fly-to-Trim  Package 

AEROELASTIC  STABILITY 

SUBSYSTEM 

300 

2.5 

9K 

DPC 

1.  Linear  Aeroelastic  Stability 

Analysis  Package 

600 

4.5 

3 OK 

CS 

2.  Floquet  Analysis  Package 

800 

6.0 

35K 

CS 

3.  Aeroelastic  Stability  Post- 

processing Package 

ACOUSTICS  SUBSYSTEM 

200 

1.0 

6K 

CS 

1.  Sound  Propagation  Package 

GENERAL  MATHEMATICAL 
OPERATIONS  SUBSYSTEM 

500 

4.0 

15K 

CS 

1.  Matrix  Inversion  Package 

800 

4.5 

40K 

DPC 

2.  Moving  Block  Fast  Fourier 

Transform  Package 

400 

2.5 

20K 

DPC 

Prony's  Method  Package 
Statistical  Functions  Package 


3 

4 


600 

400 


3.5 

2.5 


30K 

20K 


DPC 

DPC 


Table  15.  Build  4*  of  the  Operational  Complex  (3  of  3) 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOFI 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

EXTERNAL  MODELS  INTERFACE 
SUBSYSTEM 

1.  External  Model  I Package 

100 

0.5 

3K 

DPC 

EXECUTIVE  COMPONENT 

USER  INTERFACE  SUBSYSTEM 

* 

1.  User  Input  Subpackage  JV 

1000 

5.5 

20K 

DPC 

2.  User  Output  Subpackage  IV 

1000 

5.5 

20K 

DPC 

TOTAL 



9250 

.. 

56.5 

342 
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Table  16.  Build  5*  of  the  Operational  Complex 


ADDED  FUNCTION: 


Provide  the  First  Level  Release  capability  on  the  Host  2 Computer 
family 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
COOE 

ESTIMATEL 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

EXECUTIVE  COMPONENT 

OPERATING  SYSTEM  SERVICE 
SUBSYSTEM 

1.  Host  2 File  Management 

500 

4.0 

2 OK 

DPC 

2. 

Subpackage 

Host  2 Program  Management 

500 

4.0 

20K 

DPC 

3. 

Subpackage 

Host  2 Storage  Management 

500 

4.0 

20K 

DPC 

4. 

Subpackage 

Host  2 Cost  Assessment  and 

500 

3.0 

20K 

DPC 

Diagnostic  Services  Subpackage 

TOTAL 

2000 

15.0 

i 

__ 

*BUILO  5 IS  EQUIVALENT  TO  THE  FIRST  LEVEL  RELEASE  CAPABILITY  (BUILDS  1 TO  41  OPERATING  ON  A HOST  2 
COMPUTER 

’dPC  - DEVELOPMENT  PHASE  CONTRACTOR  WITH  INTEGRATED  TEAM 
MEMBER  SUBCONTRACTOR 

CS  • CPCI  SUBCONTRACTOR 
GF  • GOVERNMENT  FURNISHED 


Table  17.  Build  6 of  the  Operational  Complex  (1  of  4) 


Perform  Preliminary  Design  Airframe  Loads  Analysis 
Perform  Preliminary  Design  Engine/Drive  System  Loads 
Analysis 

Perform  Preliminary  Design  Control  System/Pilot  Loads 
Analysis 

Perform  Detailed  Design  Acoustics  Analysis 
Perform  Research  Performance  Analysis 
Perform  Research  Acoustics  Analysis 
Expand  the  Detailed  Design  Rotor  Loads  Analysis  Capa- 
bility 

Provide  an  initial  circulation  control  rotor  capability 
Provide  for  auxiliary  propulsion 
Expand  the  wake  analysis  capability 

Provide  a rotor-to-rotor  and  rotor-to-aerodynamic-surface 
analysis  capability 

Allow  the  user  to  define  output  report  formats 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

EST;  MATED 
DEVELOP- 
MENT 
LABOR 
(MAN- 
MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

TECHNOLOGY  COMPONENT 

SIMULATION  MODEL  SUBSYSTEM 

1.  Elastic  Substructured  Rotor 
Analysis  Subpackage 

1200 

9.0 

60K 

GF 

2.  Semi-Empirical  Circulation 
Control  Rotor  Subpackage 

250 

1.5 

8K 

GF 

OPC  - DEVELOPMENT  PHASE  CONTRACTOR  WITH  INTEGRATED  TEAM 
MEMBER  SUBCONTRACTOR 

CS  • CPCI  SUBCONTRACTOR 
OF  • GOVERNMENT  FURNISHED 


. • • ", 
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Table  17.  Build  6 of  the  Operational  Complex  (2  of  4) 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
COOE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHSI 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE' 

SIMULATION  MODEL  SUBSYSTEM 
(Continued) 

3.  Semi-Empirical  Reaction  Drive 

250 

1.5 

8K 

GF 

Rotor  Subpackage 

4.  Rotor  Out-of-Plane  Pendulum 

200 

1.0 

6K 

DPC 

Subpackage 

5.  Rotor  In-Plane  Pendulum 

200 

1.0 

6K 

DPC 

Subpackage 

6.  Rotor  Control  Load  Reduction 

200 

1.0 

6K 

DPC 

Devices  Subpackage 

7.  Engine  Governor  and  Fuel  Control 

. 500 

3.0 

15K 

GF 

Subpackage 

8.  Auxiliary  Propulsion  Subpackage 

too 

0.5 

3K 

DPC 

9.  Rigid  Gearbox  Subpackage 

200 

1.0 

6K 

DPC 

10.  Static  Elastic  Torsion  Gearbox 

300 

1.5 

9K 

DPC 

Subpackage 

* 

11.  Static  Elastic  Drivebelt 

100 

0.5 

3K 

GF 

Subpackage 

12.  Clutch  Analysis  Subpackage 

200 

1.0 

6K 

DPC 

13.  Drive  System  Loads  and  Vibra- 

1000 

5.5 

30K 

DPC 

tions  Subpackage 

14.  Dynamic  Test  Stand  Subpackage 

400 

2.5 

12K 

DPC 

15.  Static  Elastic  Pylon  Subpackage 

300 

1.5 

9K 

DPC 

16.  Static  Elastic  Aerodynamic 

200 

' 

6K 

DPC 

Surface  Subpackage 

17.  Rigid  Suspended  Cargo  Subpackage 

200 

6K 

DPC 

18.  Vibration  Control  Devices 

300 

1.5 

9K 

DPC 

Subpackage 

19.  Fuel  Subpackage 

400 

2.5 

12K 

DPC 

20.  Free  Wake  Subpackage 

3000 

17.0 

110K 

GF 

21.  Table  Look-Up  Flow  Field 

500 

3.0 

15K 

DPC 

Subpackage 



Table  17.  Build  6 of  the  Operational  Complex  (3  of  4) 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE' 

SIMULATION  MODEL  SUBSYSTEM 
(Continued) 

22.  Rotor-to-Rotor  Interference 

500 

4.0 

2 OK 

GF 

Subpackage 

23.  Rotor-to-Aerodynamic  Surface 

500 

4.0 

2 OK 

GF 

Interference  Subpackage 

24.  Non  rotating  Aerodynamic  Surface 

3000 

22.5 

90K 

GF 

Potential  Flow  Subpackage 

25.  Semi-Empirical  Circulation 

150 

1.0 

5K 

GF 

Control  Aerodynamics  Subpackage 
26.  Analytical  Wind  Tunnel  Boundary 

1500 

17.0 

45K 

GF 

Conditions  Subpackage 

27.  Empirical  Wind  Tunnel  Boundary 

250 

2.0  - 

8K 

GF 

Conditions  Subpackage 

TRIM  SOLUTION  SUBSYSTEM 

1.  Decoupled  Iterate-to-Trim 

1000 

7.5 

30K 

DPC 

Package 

MANEUVER  SUBSYSTEM 

1.  Gust  Response  Package 

400 

2.5 

12K 

DPC 

2.  Initiate  Failure/Damage  Effects 

150 

1.0 

5K 

DPC 

Package 

ACOUSTICS  SUBSYSTEM 

1.  Rotor  Rotational  Sound  Subpackage 

1000 

7.5 

30K 

GF 

2.  Rotor  Broadband  Sound 

200 

1.5 

6K 

GF 

Subpackage 

3.  Reciprocating  Engine  Sound 

200 

1.5 

6K 

GF 

Subpackage 

4.  Turbine  Engine  Sound  Subpackage 

250 

2.0 

8K 

GF 

I 
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Table  17.  Build  6 of  the  Operational  Complex  (4  of  4) 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE) 

ACOUSTICS  SUBSYSTEM 
(Continued) 

5.  Gearbox  Sound  Package 

2.0 

8K 

GF 

6.  Accessor  .es  Sound  Package 

4.0 

15K 

GF 

EXECUTIVE  COMPONENT 

USER  INTERFACE  SUBSYSTEM 

1.  User  Input  Subpackage  V 

1000 

5.5 

DPC 

2.  User  Output  Subpackage  V 

1000 

5.5 

2 OK 

DPC 

TOTAL 

21850 



149.0 

f 
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Table  18.  Build  7 of  the  Operational  Complex  (1  of  4) 


ADDED  FUNCTIONS: 

1.  Perform  Detailed  Design  Airframe  Loads  Analysis 

2.  Provide  Detailed  Design  Engine/Drive  System  Loads  Analysis 

3.  Provide  Detailed  Design  Control  System/Pilot  Loads  Analysis 

4.  Perform  Research  Performance  Analysis 

5.  Perform  Research  Stability  and  Control  Analysis 

6.  Perform  Research  Rotor  Loads  Analysis 

7.  Perform  Research  Airframe  Loads  Analysis 

8.  Perform  Research  Engine/Drive  System  Loads  Analysis 

9.  Perform  Research  Aeroelastic  Stability  Analysis 

10.  Provide  dynamic  teetering/gimbaled  rotor  analysis 

11.  Provide  more  detailed  control  system/pilot,  engine/drive 
system,  and  airmass  models 

12.  Provide  more  complex  ground/deck  surface  models 

13.  Allow  the  user  to  specify  alternative  analysis  techniques 

14.  Process  the  Accuracy  Assessment  Section  of  user  input 

15.  Provide  the  capability  to  assess  the  accuracy  of  an  analysis 

16.  Generate  cost  prediction  information  for  an  analysis  run 

17.  Provide  a direct  interface  to  the  user  on  an  interactive  termi- 
nal for  input  data  preparation  and  output  data  Inspection 

18.  Provide  an  interactive  tutorial  capability  to  assist  the  user  in 
preparing  valid  input  data 


Table  18, 


Build  7 of  the  Operational  Complex  (2  of  4) 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

TECHNOLOGY  COMPONENT 

SIMULATION  MODEL  SUBSYSTEM 

1. 

Rotor  Servo  Flaps  Subpackage 

200 

1.0 

6K 

GF 

2. 

Static  Elastic  Control  System 
Subpackage 

300 

2.5 

9K 

DPC 

3. 

Dynamic  Control  System  Sub- 
package 

300 

2.5 

9K 

DPC 

4. 

Control  System  Loads  and 
Vibrations  Subpackage 

600 

4.5 

20K 

DPC 

5. 

Force  Feel  System  Subpackage 

800 

6.0 

25K 

DPC 

6. 

Simple  Circulation  Control 

Rotor  Control  System  Sub- 
package 

100 

1.0 

3K 

GF 

7. 

Engine  Manufacturers  Simula- 
tion Subpackage 

500 

4.0 

15K 

GF 

8. 

Detailed  Engine  Analysis  Sub- 
package 

500 

4.0 

15K 

GF 

9. 

Reaction  Drive  Subpackage 

200 

1.5 

6K 

GF 

10. 

Circulation  Control  Drive  Sub- 
package 

300 

2.5 

9K 

GF 

11. 

Dynamic  Torsion  and  Bending 
Drlveshaft  Subpackage 

300 

2.5 

9K 

DPC 

12. 

Dynamic  Torsion  Gearbox  Sub- 
package 

500 

4.0 

15K 

DPC 

13. 

Dynamic  Torsion  Drive  Belt 
Subpackage 

300 

2.5 

• 

9K 

DPC 

14. 

Dynamic  Fuselage/Airframe 
Subpackage 

1000 

7.5 

30K 

DPC 

'oPC  - DEVELOPMENT  PHASE  CONTRACTOR  WITH  INTEGRATED  TEAM 
MEMBER  SUBCONTRACTOR 

CS  - CPCI  SUBCONTRACTOR 
GF  - GOVERNMENT  FURNISHED 


Table  18.  Build  7 of  the  Operational  Complex  (3  of  4) 


I 

\ 

( 

I 
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CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

SIMULATION  MODEL  SUBSYSTEM 
(Continued) 

■ 

15. 

Dynamic  Pylon  Subpackage 

4.5 

18K 

DPC 

16. 

Dynamic  Aerodynamic  Surface 
Subpackage 

mg 

3.0 

12K 

DPC 

17. 

Detailed  Landing  Gear  Sub- 
package 

700 

5.0 

21K 

DPC 

18. 

Dynamic  Suspended  C argo  Sub- 
package 

600 

4.5 

18K 

GF 

19. 

Cable  Subpackage 

400 

3.0 

12K 

GF 

20. 

Suspended  Cargo  Stabilization 
Devices  Subpackage 

300 

2.5 

9K 

GF 

21. 

Hoist  and  Load  Isolation  Sub- 
package 

200 

1.5 

6K 

GF 

22. 

Airframe  Loads  and  Vibrations 
Subpackage 

500 

4.0 

15K 

DPC 

23. 

Dynamic  Stores  Subpackage 

500 

4.0 

15K 

DPC 

24. 

Fuselage  to  Aerodynamic  Sur- 
face Interference  Subpackage 

1000 

7.5 

36K 

GF 

25. 

Aerodynamic  Panel  Method  for 
Arbitrary  Bodies  Subpackage 

4000 

30.0 

120K 

GF 

26. 

Cable  Aerodynamics  Subpackage 

100 

1.0 

3K 

GF 

27. 

Dynamic  Elastic  Ground/Deck 
Surface  Subpackage 

300 

2.5 

11K 

DPC 

28. 

Elastic/Plastic  Ground/Deck 
Surface  Subpackage 

400 

3.0 

15K 

DPC 

29.  Water  Surface  Subpackage 

ACCURACY  ASSESSMENT  SUBSYSTEM 

400 

3.0 

15K 

DPC 

1. 

Set  Up  Accuracy  Assessment 
Cases  Package 

700 

8.0 

21K 

GF 

2. 

Compute  Sensitivity  Factors 
Package 

500 

6.0 

15K 

GF 
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Table  18.  Build  7 of  the  Operational  Complex  (4  of  4) 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

ACCURACY  ASSESSMENT  SUBSYSTEM 
(Continued) 

3.  Generate  Expected  Values  and 

500 

6.0 

15K 

GF 

Ranges  Package 

4.  Compare  Computed  Values 

400 

4.5 

12K 

GF 

Versus  Experimental  Data 
Package 

EXECUTIVE  COMPONENT 

USER  INTERFACE  SUBSYSTEM 

1.  User  Input  Subpackage  VI 

1000 

7.5 

20K 

DPC 

2.  User  Output  Subpackage  VI 

1000 

7.5 

DPC 

3.  Interactive  Terminal  Package 

10000 

76.0 

200K 

DPC 

OPERATING  SYSTEM  SERVICES  SUB- 
SYSTEM 

1.  Host  1 Interactive  Terminal 

1000 

7.5 

20K 

DPC 

Management  Subpackage 

TOTAL 

31400 

248.0 

' !> 
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Table  19.  Build  8*  of  the  Operational  Complex  (1  of  2) 


I 

) 

l 

) 

l 


ADDED  FUNCTIONS: 


1.  Perform  Research  Control  System/Pilot  Loads  Analysis 

2.  Provide  a reaction  drive  rotor  model 

3.  Provide  automatic  flight  control  system,  control  feedback,  and 
pilot  transfer  models 

4.  Provide  a generalized  aerodynamic  interference  analysis  model 

5.  Allow  the  user  to  describe  desired  plot  formats 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

TECHNOLOGY  COMPONENT 

SIMULATION  MODEL  SUBSYSTEM 

1.  Reaction  Drive  Rotor  Subpackage 

500 

4.0 

15K 

GF 

« 

2. 

Automatic  Flight  Control  System 

4.0 

15K 

GF 

3. 

Subpackage 

Control  Feedback  From  Force/ 

400 

3.0 

12K 

GF 

4. 

Motion  Sensors  Subpackage 

Pilot  Transfer  Function  Sub- 

500 

4.0 

15K 

GF 

L ^ 

5. 

package 

Unsteady  Airloads  With  Time 

200 

2.5 

8K 

GF 

6. 

Delay  Subpackage 

General  Purpose  Aerodynamic 

2000 

23.0 

75K 

GF 

- ? , 

Interference  Subpackage 

• 

* 

*BUILD  8 IS  EQUIVALENT  TO  THE  SECOND  LEVEL  RELEASE  CAPABILITY 


’0PC  - DEVELOPMENT  PHASE  CONTRACTOR  WITH  INTEGRATED  TEAM 
MEMBER  SUBCONTRACTOR 

C3  - CPCI  SUBCONTRACTOR  * 

GF  - GOVERNMENT  FURNISHED 

f 

i 
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Table  19.  Build  8*  of  the  Operational  Complex  (2  of  2) 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE1 

EXECUTIVE  COMPONENT 

USER  INTERFACE  SUBSYSTEM 

1.  User  Input  Subpackage  VII 

1000 

5.5 

20K 

DPC 

2.  User  Output  Subpackage  VII 

1000 

5.5 

20K 

DPC 

OPERATING  SYSTEM  SERVICE  SUB- 

SYSTEM 

1.  Host  2 Interactive  Terminal 

500 

4.0 

20K 

DPC 

Management  Subpackage 

! 

TOTAL 

6600 

55.5 

« 


i 
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the  executive  control  of  the  System  and  the  user  interface  with  the  System  (i.e. , 
the  Executive  Component).  Within  each  component,  software  elements  are  ordered 
by  subsystem,  where  a subsystem  represents  a collection  of  related  capabilities. 

5.4. 2 Implementation  Plan  for  the  Support  Complex 

Four  builds  are  planned  for  the  Support  Complex.  The  first  three  builds  (A,  B,  C) 
provide  all  the  automated  tools  needed  to  support  the  development,  test,  configura- 
tion control,  release,  documentation,  and  maintenance  of  the  System  software  and 
data  on  a Host  1 computer  (EBM  S/370,  IBM  S/360).  The  fourth  build  (Build  D) 
provides  similar  tools  on  a Host  2 computer  (CDC  6000,  CDC  CYBER). 

Figure  42  presents  the  planned  schedule  for  developing  the  Support  Complex.  The 
schedule  indicates  that  the  Support  Complex  will  be  available  for  Government 
acceptance  testing  18  months  into  the  Development  Phase.  However,  individual 
software  elements  of  the  Support  Complex  will  be  made  available  to  Operational 
Complex  CPCI  subcontractors  as  each  software  element  is  completed. 

The  Support  Complex  development  schedule  presents  the  same  15  milestone  events 
as  were  presented  in  Figure  40  for  the  Operational  Complex.  Having  the  same 
milestone  events  ensures  that  the  visibility  afforded  the  Government  into  the  Sup- 
port Complex  development  efforts  equals  the  visibility  provided  into  the  Opera- 
tional Complex  development  efforts.  Each  event  identified  in  the  Support  Complex 
development  schedule  serves  the  same  function  as  the  corresponding  event  in  the 
Operational  Complex  development  schedule.  To  augment  the  visibility  afforded  by 
these  15  events,  the  intermediate  releases  (builds)  of  the  Support  Complex  will  be 
provided  for  Government  use,  thus  permitting  the  Government  to  assess  progress 
based  on  actual  System  use. 

Because  the  Support  Complex  provides  support  tools  needed  to  develop  Opera- 
tional Complex  software,  the  capabilities  in  and  the  schedule  for  each  Support 
Complex  build  must  be  time?phased  with  the  Operational  Complex  builds. 
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Figure  43  illustrates  the  time-phased  integration  of  the  implementation  and  testing 
schedules  of  the  Operational  Complex  and  the  Support  Complex  builds. 

The  first  Support  Complex  build  establishes  a basic  development  and  testing  en- 
vironment and  is  therefore  scheduled  for  completion  by  the  time  implementation 
efforts  begin  on  the  Operational  Complex,  i.e. , 9 months  after  the  initiation  of  the 
Development  Phase.  The  second  Support  Complex  build  provides  an  enhanced  soft- 
ware development  and  testing  environment,  as  well  as  automated  tools  needed  both 
to  control  the  System  software  and  data  configuration,  and  to  generate  module  de- 
sign specifications  for  inclusion  in  Type  C5  Product  Specifications.  The  second 
build  is  planned  for  completion  before  implementation  efforts  begin  on  the  second 
Operational  Complex  build  and  in  time  to  support  the  testing  efforts  for  the  first 
Operational  Complex  build,  i.e. , 11  months  after  the  initiation  of  the  Development 
Phase.  The  third  Support  Complex  build  provides  the  remaining  testing,  docu- 
mentation, and  configuration  management  support  tools.  This  build  is  planned 
for  completion  by  the  time  implementation  efforts  begin  on  build  3 of  the  Opera- 
tional Complex  and  in  time  to  support  the  testing  efforts  for  the  second  Operational 
Complex  build.  The  fourth  Support  Complex  build  provides,  on  a Host  2 computer, 
the  same  level  of  automated  support  for  development,  testing,  configuration  con- 
trol, release,  documentation,  and  maintenance  as  is  provided  on  a Host  1 computer 
at  the  conclusion  of  the  third  Support  Complex  build  (C).  The  fourth  Support  Com- 
plex build  is  planned  for  completion  by  the  time  implementation  efforts  begin  on 
the  fifth  build  of  the  Operational  Complex.  The  time-phasing  of  these  latter  two 
build  schedules  is  very  Important.  Build  5 of  the  Operational  Complex  involves 
installing  the  First  Level  Release  on  a Host  2 computer.  Build  D of  the  Support 
Complex  provides  the  support  needed  to  install  the  Host  1 transportable  System 
software  and  data  on  a Host  2 computer. 

The  CPCIs  in  each  Support  Complex  build  table,  1.  e. , Tables  20  through  23,  are 
presented  in  the  hierarchical  framework  of  the  Support  Complex  so  that  CPCI 
functional  relationships  can  be  understood.  Within  each  build  table,  CPCIs  are 
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Table  20.  Build  A of  the  Support  Complex 

FUNCTIONS: 


1.  Create,  update,  and  edit  alphanumeric  text  in  an  interactive 
or  batch  mode  on  a Host  1 computer 

2.  Generate  object  modules  from  FORTRAN  and  assembly  language 
source  modules  on  a Host  1 computer 

3.  Build  executable  load-modules  from  object  modules  on  a 
Host  1 computer 

4.  Debug  executable  load-modules  in  an  interactive  or  batch  mode  f 

on  a Host  1 computer 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE’ 

Host  1 Operating  System  Support 

1000^ 

7.52 

N/A 

HOS 

TOTAL 

1000 

7.5 

'dPC  * DEVELOPMENT  PHASE  CONTRACTOR  WITH  INTEGRAL  TEAM 
MEMBER  SUBCONTRACTOR 

HOS  - HOST  COMPUTER  OPERATING  SYSTEM 
CSV  - COMMERCIAL  SOFTWARE  VENDOR 

2THIS  ESTIMATE  REFLECTS  CODE  NEEDED  TO  VERIFY  AVAILABILITY  OF 
OPERATING  SYSTEM  CAPABILITIES. 


Table  21.  Build  B of  the  Support  Complex  (1  of  2) 


ADDED  FUNCTIONS: 


1.  Allow  the  use  of  structured-programming  control  statement 
extensions  to  ANSI  (X3. 9-1966)  FORTRAN 

2.  Assess  conformance  of  source  modules  to  programming 
standards 

3.  Monitor  scope  of  module,  CPCI,  and  integration  tests 

4.  Control  the  System  software  and  data  configuration  on  Host  1 
computers 

5.  Generate  module  design  specifications  directly  from  the 
Prologs  in  source  modules 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE) 

DEVELOPMENT  SUPPORT  SUBSYSTEM 

1.  Structured  Preprocessor  Pack- 
age 

15002 

11. 52 

5 OK 

CSV 

2.  Automated  Code  Auditor  Package 

TESTING  SUPPORT  SUBSYSTEM 

2000 

15.0 

70K 

DPC 

1.  Decision  Path  Monitor  Package 

CONFIGURATION  MANAGEMENT 
SUPPORT  SUBSYSTEM 

30002 

22. 52 

. 

100K 

CSV 

1.  Host  1 Configuration  Control 
Subpackage 

2000 

15.0 

70K 

DPC 

’oPC  - DEVELOPMENT  PHASE  CONTRACTOR  WITH  INTEGRATED  TEAM 
MEMBER  SUBCONTRACTOR 

CSV  - COMMERCIAL  SOFTWARE  VENDOR 
GF  - GOVERNMENT  FURNISHED 

^IS  ESTIMATE  NOT  INCLUDED  IN  THE  BUILD  TOTAL  BECAUSE  PURCHASE/LEASE  IS  RECOMMENDED 
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Table  22.  Build  C of  the  Support  Complex 


ADDED  FUNCTIONS: 


Generate  data  for  testing  modules  and  CPCIs 

Control  the  content  of  the  Master  Data  Base  and  Master  Command 

File 

Install  the  System  on  Governjnent-speclfled  Host  1 computers 
Identify  module  and  COMMON  block  cross-reference  for  inclusion 
in  the  dictionary  of  computer  variables 


CONTENTS 


EXE- 

CUTABLE 

CODE 


CPCI  IDENTIFICATION 


TESTING  SUPPORT  SUBSYSTEM 

1.  Test  Data  Generation  Package 

CONFIGURATION  MANAGEMENT 
SUPPORT  SUBSYSTEM 

1.  Data  Base  Support  Package 

2.  Host  1 System  Installation 
Subpackage 

DOCUMENTATION  SUPPORT 
SUBSYSTEM 

1.  Comprehensive  Cross  Reference 
Package 

TOTAL 


DPC  - DEVELOPMENT  PHASE  CONTRACTOR  WITH  INTEGRAL  TEAM 
MEMBER  SUBCONTRACTOR 

HOS  - HOST  COMPUTER  OPERATING  SYSTEM 
CSV  - COMMERCIAL  SOFTWARE  VENOOR 


ESTIMATED  ESTIMATED 

LINES  OF  “VELOP.  ESTIMATED  canq.oatE 


MENT 

LABOR 

iMAN- 

MONTHS) 


MEMORY 

REQUIRE- 

MENTS 


SOFTWARE 

SOURCE’ 


361 


Table  23 


Build  D of  the  Support  Complex 


ADDED  FUNCTIONS: 


1.  Create,  update,  and  edit  alphanumeric  text  in  an  interactive  or 
batch  mode  on  a Host  2 computer 

2.  Generate  object  modules  from  FORTRAN  and  assembly  language 
source  modules  on  a Host  2 computer 

3.  Build  executable  load  modules  from  object  modules  on  a Host  2 
computer 

4.  Debug  executable  load-modules  in  an  interactive  or  batch  mode 
on  a Host  2 computer 

5.  Transfer  transportable  System  software  and  data  from  a Host  1 
development  computer  to  a Host  2 development  computer 

6.  Install  the  System  on  Government-specified  Host  2 computers 


CONTENTS: 


CPCI  IDENTIFICATION 

ESTIMATED 
LINES  OF 
EXE- 
CUTABLE 
CODE 

ESTIMATED 

DEVELOP- 

MENT 

LABOR 

(MAN- 

MONTHS) 

ESTIMATED 

MEMORY 

REQUIRE- 

MENTS 

CANDIDATE 

SOFTWARE 

SOURCE’ 

Host  2 Operating  System  Support 

iooo2 

7.52 

N/A 

HOS 

CONFIGURATION  MANAGEMENT 

SUPPORT  SUBSYSTEM 

• 

1.  Host  2 Configuration  Control 

1000 

5.5 

70K 

DPC 

Subpackage 

2.  Host  2 System  Installation  Sub- 

1000 

7.5 

80K 

DPC 

package 

TOTAL 

3000 

20.5 

’dPC  - DEVELOPMENT  PHASE  CONTRACTOR  WITH  INTEGRAL  TEAM 
MEMBER  SUBCONTRACTOR 

HOS  - HOST  COMPUTER  OPERATING  SYSTEM 
CSV  - COMMERCIAL  SOFTWARE  VENDOR 

2THIS  ESTIMATE  REFLECTS  CODE  NEEOED  TO  VERIFY  AVAILABILITY  OF 
OPERATING  SYSTEM  CAPABILITIES. 
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generally  ordered  by  subsystem,  where  a subsystem  represents  a collection  of 
related  sujjport  capabilities.  Two  Support  Complex  CPCIs,  the  Host  1 Operating 
System  Support  CPCI  and  the  Host  2 Operating  System  Support  CPCI,  do  not  pro- 
vide capabilities  unique  to  a subsystem.  These  two  special  CPCIs  provide  both 
development  and  testing  support  capabilities. 

The  candidate  source  for  two  Support  Complex  CPCIs  in  build  B is  identified  ! 

as  a "Commercial  Software  Vendor."  These  two  CPCIs  are  the  Structurfed  Pre-  | 

i 

t processor  CPCI  and  the  Decision  Path  Monitor  CPCI.  Transportable  software 

packages  which  provide  the  needed  CPCI  capabilities  are  available  from  various  j 

commercial  software  vendors  at  a cost  considerably  less  than  the  cost  of  ^ 

developing  the  capabilities  expressly  for  the  System.  The  estimated  development  j 

labor  for  these  two  CPCIs  has  therefore  not  been  included  in  the  build  B table.  j 

' 

4'  i j 
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SECTION  6 - RISK  CONSIDERATIONS 


r 


Three  risk  considerations  associated  with  the  System's  helicopter  analysis  capa- 
bility have  been  identified  (Section  6. 1).  In  addition,  four  risk  considerations 
associated  with  the  effect  of  executive  overhead  on  the  economy  of  System  utiliza- 
tion have  also  been  identified  (Section  6. 2). 

The  risk  considerations  discussed  do  not  represent  inherent  deficiencies,  rather 
they  represent  specific  System  capabilities  and  characteristics  which  could  have 
a major  impact  on  the  acceptability  of  the  System  if  they  are  not  factored  into  any 
System  design. 

For  each  risk  consideration  discussed,  various  alternatives  that  could  increase  or 
decrease  risk  are  identified,  evaluation  criteria  are  presented  and  used  to  assess 
the  alternatives,  and  the  extent  to  which  each  risk  consideration  has  been  accounted 
for  is  discussed. 

6. 1 HELICOPTER  ANALYSIS  RISK  CONSIDERATIONS 

Three  risk  areas  potentially  affecting  helicopter  analysis  have  been  identified: 
component  coupling  (Section  6. 1. 1),  aerodynamic  flow  field  analysis  (Sec- 
tion 6. 1.2),  and  numerical  integration  (Section  6. 1.3). 

6. 1. 1 Coupling  of  Components 

The  System  should  allow  the  engineering  user  to  defirie  the  configuration  to  be 
analyzed  in  terms  of  the  components  making  up  the  configuration.  Further,  the 
System  should  allow  the  engineering  user  to  define  and  analyze  each  component 
Independent  of  its  final  relationship  (1.  e. , coupling)  with  other  components  within 
the  configuration.  Without  these  two  capabilities,  the  engineering  user  would 
have  to  redefine  each  component  as  a function  of  the  configuration  to  be  analyzed, 
thus  significantly  reducing  both  the  usability  and  the  acceptability  of  the  System 
within  the  helicopter  analysis  community. 
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Within  the  non-rotory-wing  aerospace  community,  the  importance  of  these  two 
capabilities,  1.  e. , defining  a configuration  in  terms  of  its  components  and  de- 
fining each  component  independently,  has  long  been  recognized.  For  this  reason, 
structural  analysis  programs  used  within  the  aerospace  industry  include  these 
two  capabilities,  along  with  systematic  and  accurate  methods  for  coupling  the 
components  (e.  g. , NASTRAN).  None  of  the  first  generation  helicopter  analysis 
programs  includes  a general  and  systematic  approach  for  analyzing  a coupled 
configuration  of  independently  defined  components.  Because  of  this  lack  of  ex- 
1 perience,  component  coupling  can  be  considered  potentially  risky  for  the  Second 

Generation  Comprehensive  Helicopter  Analysis  System.  However,  the  feasibility, 
utility,  and  validity  of  component  coupling  have  been  proved  elsewhere  in  the 
aerospace  industry. 

There  are,  however,  two  other  risk  factors  associated  with  the  application  of  com- 
ponent coupling  technology  to  rotary-wing  aircraft:  First,  is  component  coupling 
feasible  when  a configuration  is  composed  of  both  rotating  and  nonrotating  com- 
ponents ? Second,  which  method  or  methods  should  be  employed  to  couple  compo- 
nents ? 

Section  2. 1.3  of  this  report  specifically  addresses  the  feasibility  of  component 
coupling  for  helicopter  configurations  and  numerous  state-of-the-art  methods  for 
effecting  component  coupling.  Component  coupling  is  feasible  for  helicopter  con- 
figurations as  long  as  all  transformations  associated  with  rotating  coordinate 
systems  are  performed  within  the  individual  components  before  components  are 
coupled  together. 

The  method  for  coupling  of  components  to  be  used  in  the  System  represents  the 
last  risk  factor  associated  with  component  coupling.  The  selected  method  must 
satisfy  three  Important  criteria: 

t 

• The  degrees  of  freedom  in  the  coupled  configuration  should  be  a sub- 
set of  the  degrees  of  freedom  in  the  uncoupled  configuration.  (This 
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reduces  the  number  of  degrees  of  freedom  to  be  carried  into  subse- 
quent analysis  steps,  thus  reducing  the  cost  of  the  analysis. ) 

• The  method  selected  must  permit  a totally  independent  analysis  of 
each  component.  (This  allows  the  engineering  user  to  analyze  com- 
ponents separately  and  then  to  define  a configuration  made  up  of  the 
components . ) 

• The  method  selected  must  be  compatible  with  test  procedures  com- 
monly used  throughout  the  helicopter  industry,  both  with  respect  to 
defining  System  input  which  is  derived  from  test  results  and  with 
respect  to  using  test  results  to  validate  the  analysis  results  produced 
by  the  System. 


Coupling  of  components  can  be  accomplished  by  two  different  methods.  The  first 

method  is  commonly  referred  to  as  substructure  analysis.  One  of  the  earliest 

comprehensive  discussions  of  this  method  was  presented  by  Przemieniecki.10 

The  second  method,  commonly  called  the  method  of  component  modes,  was  first 
11  12 

proposed  by  Hurty.  ’ This  method  and  others  derived  from  it  have  since  re- 

. . . 13  through  25 

ceived  much  attention. 


In  both  of  these  methods,  a complex  structure  is  considered  to  be  made  up  of 
component  substructures  connected  at  specified  node  points,  and  the  behavior  of 
the  structure  is  determined  by  considering  the  behavior  of  the  component  substruc- 
tures at  the  connection  node  points.  The  essential  difference  between  the  two 
methods  lies  in  the  different  manner  in  which  the  behavior  of  the  component 
substructures  is  represented.  In  substructure  analysis,  the  component  substruc- 
tures are  represented  in  terms  of  mass,  damping,  and  stiffness  properties  at  the 
connecting  node  points,  whereas,  in  the  component  modes  method,  the  substruc- 
tures are  represented  by  their  modal  data  (eigenvalues  and  eigenvectors).  The 
chief  advantage  of  the  component  modes  method  over  the  substructure  analysis 
method  is  that  reliable  results  can  normally  be  obtained  using  significantly  fewer 


I 

t 

I 

i 
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degrees  of  freedom  than  are  needed  in  substructure  analysis.  This  satisfies  the 
first  criterion  that  a method  of  coupling  should  satisfy. 

The  substructure  analysis  method,  because  of  its  reliance  on  mass,  damping,  and 
stiffness  properties  at  connecting  node  points,  is  not  compatible  with  test  proce- 
dures commonly  used  throughout  the  helicopter  industry.  Mass,  damping,  and 
* stiffness  properties  at  connecting  node  points  cannot  be  obtained  from  nondestruc- 

tive tests.  Therefore,  System  input  for  the  substructure  analysis  method  is 

rarely  derivable  from  tests.  However,  System  data  for  the  component  modes 
f 

method  is  derivable  from  nondestructive  tests  if  the  proper  component  modes 
approach  is  used.22 

Several  approaches  to  the  component  modes  method  have  been  proposed  by  various 

11  12 

investigators.  The  approach  suggested  by  Hurty,  * and  variations  of  it  pro- 
posed by  others,14  t*iroug*1  17  empi0y  rigid-body  modes,  constraint  modes,  and 
normal  modes  with  fixed  constraints.  These  approaches  are  incompatible  with 
helicopter  test  procedures  because  the  required  input  data  is  very  difficult  to 

derive  from  test  data  and  because  it  is  quite  difficult  to  compare  analysis  results 

19  20 

with  test  results.  The  approaches  proposed  by  MacNeal  and  Rubin  employ 
free-body  modes  and  residual  effects.  Both  MacNeal's  and  Rubin's  approaches 
give  good  accuracy  (this  is  particularly  so  for  Rubin's  approach,  which  is  an  im- 
provement over  MacNeal's  approach)  and  are  compatible  with  helicopter  test  pro- 
cedures; both,  however,  are  restrictive  and  cumbersome  in  formulation.  More 

recently,  a general  component  modes  approach  for  inclusion  in  NASTRAN  has  been 

24 

developed  by  Herting  and  Hoesly  under  NAHA  sponsorship.  This  approach  has  the  1 

. 20 

0 accuracy  of  Rubin's  method  without  the  restriction  of  having  to  use  specific  types 

of  modes.  In  addition,  this  general  approach  obtains  the  results  of  all  the  other 
methods  referenced  as  special  cases.  This  general  approach  also  satisfies  all  the 
» three  criteria  mentioned  earlier  for  a systematic  method  of  coupling  components. 


Therefore,  the  component  modes  approach  developed  for  inclusion  in  NASTRAN  is 
the  approach  best  suited  for  inclusion  in  the  System. 


I 

* 

I 

I 
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The  CSC/BHT  System  design  can  accommodate  either  of  the  two  dynamic  coupling 
methods  mentioned  above  (i.e. , substructure  analysis  or  component  modes). 

However,  the  funds  available  for  the  Development  Phase  may  not  permit  the  im-  t 

plementation  of  both  methods.  Because  of  the  advantages  offered  by  the  NASTRAN 

component  modes  approach,  CSC  recommends  the  implementation  of  this  method 

of  coupling  for  the  First  Level  Release  of  the  System.  If  funding  permits,  it  is 

recommended  that  the  substructure  analysis  method  be  added  to  the  Second  Level 

Release  of  the  System.  It  is  also  recommended  that  the  simultaneous  use  of  both 
25 

these  methods  be  considered  for  inclusion  in  the  Long  Range  System.  ' 

6.1.2  Aerodynamic  Flow  Field  Analysis 

Aerodynamic  flow  field  analysis  is  an  essential  capability  within  both  the  fixed- 
wing  industry  and  the  rotary-wing  industry.  However,  the  effects  of  aerodynamic 
flow  fields  on  aircraft  surfaces  are  considerably  more  difficult  to  determine  for 
rotary-wing  aircraft  than  for  fixed-wing  aircraft.  For  either  type  of  aircraft, 
aerodynamic  effects  can  significantly  affect  the  performance,  loads,  vibration, 
and  stability  characteristics  of  the  aircraft.  However,  aerodynamic  flow  field 
effects  tend  to  be  more  pronounced  for  rotary-wing  aircraft  than  for  fixed-wing 
aircraft  because  of  the  proximity  and  inherent  unsteadiness  of  the  rotor  wake. 

Basic  differences  between  rotary-wing  aircraft  and  fixed-wing  aircraft,  which 

I' 

illustrate  the  increased  difficulty  of  aerodynamic  flow  field  analysis  on  rotary- 
wing aircraft.  Include  the  following: 

• The  fuselage  of  a helicopter  is  relatively  unstreamlined  compared  to 
most  fixed-wing  aircraft  fuselages.  Flow  separation  is  thus  a pro- 
portionately larger  contributor  to  fuselage  drag. 

• The  main  rotor's  wake  has,  at  all  flight  conditions,  the  possibility  of 
having  strong  interactions  with  the  main  rotor  itself,  as  well  as  with 
the  tail  rotor,  fin,  fuselage,  etc.  Thus,  the  main  rotor's  wake  can 
contribute  dominantly  unsteady  effects  in  many  flight  conditions. 


• The  main  rotor's  aerodynamic  environment  is  highly  unsteady  in  for- 
ward flight.  These  unsteady  effects  may  be  the  same  order  of  magni- 
tude as,  or  larger  than,  steady  effects. 

• Stall  may  occur  on  some  portion  of  the  rotor  in  many  flight  conditions. 
Viscous  flow  separation  effects  are  therefore  inherently  more  frequent 
than  for  fixed-wing  lifting  surfaces. 

• Rotor  free-stream  velocities  are  nonuniform  radially  for  all  flight 
conditions  and  are  also  nonuniform  azimuthally  for  forward  flight  con- 
ditions. Also,  transonic  flow  exists  on  significant  portions  of  the  rotor 
for  flight  conditions  which  make  up  a large  part  of  the  helicopter  mis- 
sion profile. 

• Wake  position,  flow  separation  regions,  and  rotor  blade  stall  are  all 
strongly  dependent  on  the  configuration  of  the  rotary-wing  aircraft  and 
flight  conditions.  Thus,  some  of  the  linearizations  and  resultant 
superposition  of  linear  solutions  employed  by  the  fixed-wing  industry 
for  flow  field  analysis  are  inherently  unsatisfactory  for  rotary-wing 
aircraft. 

Careful  attention  must  be  paid,  therefore,  to  the  aerodynamic  flow  field  analysis 
capability  selected  for  inclusion  in  the  System,  in  terms  of  its  near-term  feasi- 
bility, its  applicability,  its  reliability,  its  generality,  and  the  economy  of  its  uti- 
lization. If  the  selected  capability  does  not  achieve  all  of  these  characteristics, 
the  acceptability  of  the  System  will  be  affected.  The  functional  characteristics  of 

► 

the  generalized  flow  analysis  method  to  be  included  in  the  System  must  include  the 
following: 

i • The  representations  of  aerodynamic  surfaces  must  be  derivable  by  the 

System,  using  basic  aircraft  data  (e.g. , fuselage  lines  data,  blade 
twist,  airfoil  type,  planform  data)  and  user-specified  input  data. 
Advanced  aerodynamic  panel  elements  must  be  available  (especially 
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for  large  areas  of  the  fuselage  side  and  bottom,  tailboom  bottom, 
etc. , which  may  have  relatively  limited  interaction  with  other  aero- 
dynamic surfaces).  Methods  to  optimize  panel  size  need  to  be  devel- 
oped to  reduce  computation  time  yet  produce  acceptable  accuracy. 

• The  potential  flow  equations  and  method  fo  solution  must  be  capable 
of  modeling  all  rotary- wing  flight  conditions.  The  effects  of  unsteady 
flow,  radially  and  azimuthally  nonuniform  rotor  free  stream,  rotor(s) 
wake,  compressibility  (subsonic,  supersonic,  and,  if  possible,  tran- 
sonic), and  rotor  blade  motions  must  be  treated  in  a generalized, 
unified  manner.  New  surface  singularity  representations  are  needed 
to  avoid  numerical  instabilities  that  often  occur  when  modeling  wake 
interference  effects  such  as  blade-vortex  interactions. 

• Viscous  effects  (and,  if  necessary,  transonic  compressibility  effects) 
must  be  handled  in  an  approximate  manner  (to  reduce  computer 
costs). 

The  physical  laws  that  apply  to  the  calculation  of  aerodyanmic  forces  and  moments 
are  represented  by  the  well-known  Navier-Gtokes  nonlinear  partial  differential 
equations.  Closed-form  solutions  to  the  Navier-Stokes  equations  exist  only  for 
a very  small  number  of  simplified  special  cases.  Numerical  solution  techniques 
for  solving  the  Navier-Stokes  equations  at  acceptable  computer  costs  are  not  cur- 
rently well  developed.  However,  complete  solutions  to  the  time-dependent 
Navier-Stokes  equations  are  being  attempted  at  the  present  time  for  a variety  of 
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problems.  ’ Nevertheless,  Chapman  estimates  that  it  will  be  the  late  1980s 
before  computers  will  be  available  that  have  sufficient  speed  to  solve  these  equa- 
tions in  a "reasonable"  amount  of  time  for  fixed-wing  problems.  This  estimate 
assumes  that  computer  speeds  in  the  late  1980s  will  be  three  orders  of  magnitude 
faster  than  the  current  speed  of  the  Illiac  IV.  Rotary-wing  capabilities  will  prob- 
ably lag  behind  fixed-wing  capabilities  because  there  is  not  a simple,  straight- 
forward application  of  fixed-wing  solutions  to  rotary-wing  problems  (due  to  the 
complicating  flow  characteristics  listed  earlier).  Therefore,  rotary-wing  solu- 
tions will  probably  require  another  order  of  magnitude  increase  in  computer 
speed,  and  Navier-Stokes  solutions  for  rotary  wings  are  not  expected  to  be  in- 
cluded within  the  life  cycle  of  the  System. 


41Rudy,  D.  et  al. , AN  INVESTIGATION  OF  SEVERAL  NUMERICAL  PROCE- 
DURES FOR  TIME -ASYMPTOTIC  COMPRESSIBLE  NAVIER-STOKES  SOLU- 
TIONS, Paper  No.  14  in  Aerodynamic  Analyses  Requiring  Advanced  Computers 
(conference  held  at  NASA  Langley  Research  Genter,  Hampton,  Virginia, 

March  4-6,  1975),  pp.  437-468. 

42 

Thames,  F.  C.,  Thompson,  J.  F. , and  Mastin,  C.  W. , NUMERICAL  SOLU- 
TION OF  THE  NAVIER-STOKES  EQUATIONS  FOR  ARBITRARY  TWO- 
DIMENSIONAL  AIRFOILS,  Paper  No.  15  in  Aerodynamic  Analyses  Requiring 
Advanced  Computers  (conference  held  at  NASA  Langley  Research  Center, 
Hampton,  Virginia,  March  4-6,  1975),  pp.  469-530. 

43 

Chapman,  D.  R. , INTRODUCTORY  REMARKS,  in  Aerodynamic  Analyses  Re- 
quiring Advanced  Computers  (conference  held  at  NASA  Langley  Research  Center, 
Hampton,  Virginia,  March  4-6,  1975),  pp.  4-7. 
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A somewhat  simpler  method  would  be  to  solve  the  following  unsteady  perturbation 

44 

potential  flow  equation  : 


m“2  v2  $ - $TT  = (y  - i)  v2  $ ($T  + (v^2/2) 


+ V*  • V (2$t  + (vty  /2) 


where  M is  Mach  number,  $ is  the  velocity  potential  function,  y is  the  ratio  of 
specific  heats,  and  the  subscript  T indicates  a substantial  time  derivative  opera- 
tor which,  for  perturbations  about  a flow  U in  the  x-direction,  is  given  by 


-1  6 6 

<>T  = U 6T(>+6^> 


and  boundary  conditions  for  tangential  flow  on  the  surface,  B (x,  y,  z,  t)  = 0 , is 
given  by 


bt  + V#  • VB  = 0 


Equation  (17)  neglects  viscous  effects.  Therefore,  an  empirical  or  approximate 
method  is  needed  to  represent  flow  separation.  Some  solutions  to  this  complete 
equation  have  been  obtained,  but  general  and  reliable  methods  are  not  yet  avail- 


44Bland,  S.  R. , RECENT  ADVANCES  AND  CONCEPTS  IN  UNSTEADY  AERODY- 
NAMIC THEORY,  Paper  No.  46  in  Aerodynamic  Analyses  Requiring  Advanced 
Computers  (conference  held  at  NASA  Langley  Research  Center,  Hampton, 
Virginia,  March  4-6,  1975),  pp.  1305-1326. 


Still  another  alternative  is  to  use  a simplified  form  of  Equation  (17),  namely 


M“2V2*-^rT  = 0 (20) 

This  equation  is  equivalent  to  neglecting  transonic  flow  effects.  This  form  of 
Equation  (17)  represents  unsteady  effects  and  compressibility  effects  in  a gener- 
alized, unified  manner.  Morino  has  developed  much  of  this  capability  for  fixed- 

wing  aircraft45  and  has  done  some  work  for  both  tilting  prop-rotor  aircraft46  and 
47 

helicopters.  The  solution  represented  by  Equation  (20)  is  valid  for  airframe 
calculations  and  for  rotor-in-hover  calculations. 

The  provision  of  an  aerodynamic  potential  flow  field  analysis  capability  without 
transonic  effects  in  the  Second  Level  Release  is  recommended.  This  capability 
is  feasible,  economical  to  use,  and  represents  the  near-term  state  of  the  art. 

The  absence  of  a complete  unsteady  perturbation  potential  flow  capability  in  the 
Second  Level  Release  will  not  affect  the  acceptability  of  the  System,  because  such 
a capability  is  effectively  beyond  even  the  near-term  state  of  the  art.  However, 
the  provision  of  a partial  unsteady  perturbation  potential  flow  capability  (i.  e. , ne- 
glecting transonic  flow  effects)  as  represented  in  Equation  (20)  will  enhance  the 


45 

Morino,  L.  and  Chan,  L.-T.,  INDICIAL  COMPRESSIBLE  POTENTIAL  AERO- 
DYNAMICS AROUND  COMPLEX  AIRCRAFT  CONFIGURATIONS,  Paper  No.  38 
in  Aerodynamic  Analyses  Requiring  Advanced  Computers  (conference  held  at 
NASA  Langley  Research  Center,  Hampton,  Virginia,  March  4-6^  1975), 
pp.  1067-1110. 

46 

t Morino,  L.  et  al. , AERODYNAMIC  INTERFERENCE  EFFECTS  ON  TILTING 

PROPROTOR  AIRCRAFT,  NASA  CR-152053. 

47 

Soohoo,  P.  et  al. , ROTOR  WAKE  EFFECTS  OF  HUB /PYLON  FLOW  SEPARA- 
TION, Aerospace  Systems,  Inc. ; TR  76-38,  Vol.  1 (to  be  published  as  a 
Government  report,  under  Contract  DAAJ02-75C-0041). 
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acceptability  of  the  System  because  it  represents  a useful  and  advanced  state-of- 
the-art  capability. 

i 

It  is  suggested  that  the  Government  incorporate  into  its  plans  for  the  Long  Range 
System  the  development  of  a capability  to  solve  the  complete  unsteady  perturbation 
potential  flow  problem  as  expressed  in  Equation  (17).  This  development  effort 

/ 

should  begin  as  soon  as  reliable  solution  techniques  have  been  developed  for 

applying  Equation  (17)  to  fixed-wing  aerodynamic  analysis  problems.  In  planning 

for  the  Long  Range  System,  the  following  questions  need  to  be  given  special  con-  , 

sideration: 

• Can  we  afford  to  wait  for  the  fixed-wing  solution  ? 

■7 

• When  available,  will  the  fixed-wing  methods  be  directly  applicable  to 
rotary-wing  uses  ? 

• Will  independent  development  of  rotary- wing  methods  be  required? 

6.1.3  Numerical  Integration 

The  System  must  provide  stable  and  accurate  numerical  integration  methods  if 
acceptable  analyses  of  flight  dynamics  problems  are  to  be  achieved.  Three  types 
of  numerical  integration  methods  have  been  analyzed  by  CSC/BHT:  predictor- 

corrector  methods,  Runge-Kutta  methods,  and  direct  integration  methods. 

' 

Predictor-corrector  methods,  because  of  their  speed,  accuracy,  and  stability, 
are  ideal  for  many  applications.  However,  BHT's  experience  with  predictor- 
corrector  methods  has  shown  that  the  hi;/h  frequencies  and  forcing  function  dis- 
continuities typical  of  many  helicopter  analysis  problems  cause  even  the  best  ■» 

predictor-correction  methods  (e.g. , Hamming's  method)  to  be  very  slow  and 
sometimes  inaccurate.  Therefore,  CSC/BHT  does  not  recommend  providing  a 
predictor-corrector  numerical  integration  capability  in  the  System.  ' 
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Runge-Kutta  methods  use  various  weighting  functions  for  averaging  the  calculated 
accelerations.  Because  the  methods  are  self-starting,  they  are  inherently  insen- 
sitive to  discontinuities  in  the  forcing  functions.  The  stability  and  economy  of 
these  methods  tend  to  deteriorate  in  the  presence  of  high  frequencies.  Thus,  it 
may  be  rather  time  consuming  to  run  cases  with  very  high  frequencies.  This 
situation  can  be  improved  by  the  use  of  enhanced  Runge-Kutta  methods  (e.  g. , the 
Runge-Kutta-Felhberg  method),  which  require  fewer  function  evaluations  and 
allow  a variable  integration  interval  with  no  loss  in  accuracy  or  stability.  How- 
ever, stability  still  tends  to  deteriorate  in  the  presence  of  very  high  frequencies. 

CSC/BHT  plans  to  provide  an  enhanced  Runge-Kutta  method  as  one  of  the  available 
numerical  integration  methods  in  the  First  Level  Release.  However,  the  enhanced 
Runge-Kutta  method  will  not  be  used  for  flight  dynamics  problems  in  which  very 
high  frequencies  are  present.  CSC/BHT  plans  to  use  a direct  integration  method 
for  such  cases. 


CSC/BHT  has  studied  the  applicability  of  direct  integration  methods  to  helicopter 
flight  dynamics  problems.  Direct  integration  methods  are  widely  used  in  the 
numerical  integration  of  dynamic  equilibrium  equations  encountered  in  finite  ele- 
ment analysis.  The  term  "direct"  means  that  the  equations  involved  are  integrated 
directly  without  any  transformation.  This  is  in  contrast  to  the  modal  (or  mode 
superposition)  approach  in  which  the  dynamic  equilibrium  equations  are  first 
transformed  (prior  to  integration)  by  the  use  of  generalized  coordinates. 

Direct  numerical  integration  methods  employed  in  practice  involve  either  explicit 
or  implicit  formulations.  Explicit  formulations  are  based  on  equilibrium  condi- 
tions at  the  previous  time  step,  whereas  implicit  formulations  are  based  on  equi- 
librium conditions  at  the  current  time  step.  The  central  difference  method  is  an 

example  of  an  explicit  method,  and  the  Newmark-Beta,  Wilson-Theta,  and  Houbolt 

26 

methods  are  examples  of  implicit  methods. 

The  differences  between  explicit  and  implicit  methods  are  quite  important.  Ex- 
plicit methods  typically  require  minimal  storage  and  are  computationally  efficient. 


r 

. 


I 

j 


375 


but  are  hampered  because  their  stability  criteria  limit  the  step  sizes  that  can  be 
employed.  In  general,  these  step-size  limitations  are  related  to  the  highest  nat- 
ural frequency  of  the  system  of  equations  under  consideration.  The  implicit 
methods,  on  the  other  hand,  offer  unconditional  stability  at  the  expense  of  in- 
creased storage  and  reduced  computational  efficiency.  This  unconditional 
stability  results  from  the  introduction  of  synthetic  damping  into  the  system  of 
equations  when  very  high  frequencies  are  present,  thus  affecting  the  accuracy  of 
the  solution.  This  can  present  a potentially  serious  problem  to  the  engineer, 
because  the  integration  results  are  used  for  stability  analysis.  The  problem  can 
be  resolved  if  the  amount  of  synthetic  damping  introduced  can  be  accurately  de- 
termined by  the  System.  CSC/BHT  has  not  yet  found  an  implicit  method  pos- 
sessing this  characteristic.  However,  implicit  methods  are  particularly  suitable 
for  large  systems  of  equations  where  the  highest  natural  frequency  is  generally 
not  known  and  may,  in  fact,  approach  infinity  in  certain  cases. 

CSC  and  BHT  are  continuing  to  investigate  numerical  integration  techniques  for 
application  to  flight  dynamics  problems.  Recently,  an  unconditionally  stable 

27 

explicit  algorithm  has  been  proposed  for  certain  structural  dynamics  problems. 

Other  recent  publications  address  the  relative  stability  of  various  numerical  in- 

28 

tegration  techniques  for  vibration  problems  and  for  transient  rotor  dynamics 
29 

problems. 

6.2  EXECUTIVE  OVERHEAD  CONSIDERATIONS 

A consideration  associated  with  every  large,  general-purpose  software  system  is 
the  overhead  associated  with  executive  software.  The  design  of  an  executive  must 
address  two  types  of  overhead:  processing  overhead  and  memory  overhead. 

There  are  two  primary  areas  of  concern  with  respect  to  executive  processing 
overhead  for  the  System:  (1)  the  amount  of  time  required  to  interpret  a System 
Command  and  transfer  control  to  the  software  element  specified  by  the  System 
Command  and  (2)  the  amount  of  time  required  to  store  data  in  and  retrieve  data 
from  the  Run  Data  Base.  Section  6.2. 1 addresses  the  first  concern;  Section  6.2.2 


I 

\ 

I 

■ 

I 

> 

I 

addresses  the  second.  Section  6.2.3  discusses  the  effect  of  executive  processing 
overhead  on  the  execution  time  of  small  problems.  Section  6.2.4  addresses  exe- 
cutive design  concepts  which  will  minimize  the  amount  of  computer  memory  re-  i 

quired  by  executive  software. 

6.2.1  System  Command  Execution 

To  make  the  System  acceptable  for  use  by  the  helicopter  analysis  community,  the 
amount  of  executive  processing  overhead  must  not  contribute  significantly  to  the 
total  computer  time  required  for  an  analysis.  The  processing  overhead  associated 
with  executing  a System  Command  is  equivalent  to  the  time  expended  from  the  end 
of  execution  of  one  software  element  to  the  beginning  of  execution  of  the  next  soft- 
ware element  specified  in  a System  Command.  The  time  expended  must  be  exa- 
mined relative  to  the  execution  time  of  the  software  element. 

The  time  expended  depends  on  four  operations:  (1)  interpreting  the  System  Com- 
mand, (2)  bringing  the  software  element  into  memory  if  it  is  not  already  there, 

(3)  bringing  the  required  data  elements  into  memory  if  they  are  not  already  there, 
and  (4)  transferring  control  to  the  software  element.  The  amount  of  time  asso- 
ciated with  operations  (1)  and  (4)  is,  relative  to  operations  (2)  and  (3),  insignifi- 
cant. To  reduce  the  overhead  associated  with  operation  (2),  CSC's  design  permits 

more  than  one  software  element  per  load-module.  In  addition,  once  a load-  t ■ 

module  is  in  memory  it  is  retained  until  that  section  of  memory  is  required. 

Thus,  bringing  the  software  element  into  memory  is  the  exception  rather  than  the 

- L 

rule  and  processing  overhead  is  minimized.  To  reduce  the  overhead  associated 
with  operation  (3),  CSC  has  designed  the  System  to  allow  the  Run  Data  Base  to  be 
entirely  memory-resident  for  small  problems  and  to  be  partially  memory- resident 
for  intermediate-size  problems.  This  design  decision  virtually  eliminates  this 
type  of  processing  overhead  for  small  problems  and  reduces  it  considerably  for 
intermediate-size  problems. 

Based  on  CSC's  7-year  experience  with  the  Goddard  Real  Time  System,  a soft- 
ware system  for  real-time  processing  of  satellite  launch  data  that  uses  a 
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load-module  management  philosophy  similar  to  the  one  designed  by  CSC  for  the 
System,  CSC  estimates  that  the  processing  overhead  penalty  for  the  four  opera- 
tions described  above  for  any  one  software  element  will  amount  to  no  more  than 
9 percent  in  the  worst  case  and  considerably  less  than  that  in  the  majority  of 
cases.  The  9-percent  worst  case  overhead  penalty  applies  not  to  the  whole  prob- 

r 

lem  but  to  one  software  element  only.  The  processing  overhead  penalty  for  a } 

complete  analysis  run  will  be  considerably  less  because  operations  (2)  and  (3) 
described  above  will  seldom  occur. 

i 

There  are  many  advantages  to  using  System  Commands  to  control  processing. 

Some  of  these  are  the  increased  flexibility  the  user  has  to  view  intermediate 
output  by  printing  and  plotting  anywhere  in  the  command  sequence  and  to  build  an 
unlimited  number  of  System  Command  Sequences;  the  ability  to  improve  efficiency 
if  more  memory  is  available;  and  the  ability  to  gather  System  performance  sta- 
tistics anywhere  in  the  sequence.  These  advantages  outweigh  the  processing  over- 
head penalty  incurred. 

6. 2. 2 Data  Base  Management  Capability 

For  the  System  to  be  able  to  accommodate  new  and  improved  capability  throughout 
its  target  lifetime,  it  is  essential  to  separate  the  location  of  the  data  from  the 

internal  logic  of  software  elements.  It  is  also  essential  that  this  separation  be  t 

accomplished  in  such  a way  as  to  minimize  the  computer  time  used.  Without 
proper  care,  executive  processing  overhead  in  managing  the  data  base  could  pre- 

' ' 

vent  the  System  from  enjoying  widespread  use.  It  is  for  this  reason  that  CSC  has 
not  recommended  the  use  of  a generalized  off-the-shelf  data  base  management 
system  such  as  System  2000  or  TOTAL.  These  systems  are  designed  for  large 
data  bases  of  a business-oriented  nature  and,  while  very  powerful,  do  penalize 
the  user  with  a relatively  high  overhead.  Rather,  CSC  proposes  to  develop,  as 
part  of  the  Executive  Component,  a simple  data  base  management  capability  (as 
opposed  to  a general-purpose  data  base  management  capability)  tailored  specif- 
ically to  the  needs  of  helicopter  analysis.  CSCs  design  of  this  capability. 
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incorporated  in  the  Data  Base  Management  Subsystem,  has  the  advantage  that  data 
elements  are  retained  in  memory  (the  memory- resident  Run  Data  Base)  if  memory 
is  available . This  will  be  the  case  for  small  problems . 

6.2.3  Small  Problems 

The  primary  concern  with  respect  to  solving  small  problems,  e.g. , those  asso- 
ciated with  the  preliminary  design  aircraft  life  cycle  phase,  can  be  stated  as 
follows:  many  design  features  are  required  to  make  the  System  flexible,  extend- 
able, and  global  in  application;  these  features  may  not  be  required  for  running 
a small  problem  and  thus  the  cost  of  running  a small  problem  might  be  exorbitant. 
This  has  been  a common  complaint  about  NASTRAN.  However,  NASTRAN  was 
specifically  designed  to  solve  large  problems.  This  is  not  the  case  for  the  Second 
Generation  Comprehensive  Helicopter  Analysis  System.  It  is  a requirement  that 
the  System  solve  both  small  and  large  problems  and  that  small  problems  be  solved 
efficiently. 

It  is  to  be  expected  that,  as  problem  size  decreases,  the  relative  execution  time 
of  many  of  the  software  elements  becomes  smaller  and  thus  the  percentage  of 
executive  processing  overhead  increases.  It  is  also  to  be  expected  that  a system 
of  general  applicability  will  require  a longer  execution  time  for  any  individual 
problem  than  would  a computer  program  specially  designed  for  that  problem.  The 
goal  is  not  to  eliminate  executive  processing  overhead  for  small  problems  but  to 
limit  it  within  acceptable  bounds. 

The  principal  characteristic  of  NASTRAN  that  causes  it  to  be  inefficient  for  small 
problems  is  that  data  blocks  are  stored  on  and  retrieved  from  external  files  re- 
gardless of  the  size  of  the  problem  being  solved.  Therefore,  storing  and  re- 
trieving data  blocks  that  are  input  to  and  output  from  NASTRAN  functional  modules 
involve  physical  input/output  operations  independent  of  problem  size.  The  fixed 
overhead  penalty  associated  with  these  input/output  operations  experienced  by 
NASTRAN  users  is  avoided  in  the  System  by  keeping  data  of  the  Run  Data  Base  in 
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memory  if  memory  is  available.  For  small  problems,  the  Rim  Data  Base  will  be  * 

memory-resident,  thus  eliminating  the  overhead  associated  with  writing  and 

reading  the  Run  Data  Base  or  parts  of  it  to  and  from  external  files.  Thus,  because  i | 

of  the  memory  residence  of  the  Run  Data  Base,  small  problems  can  be  analyzed 
at  low  cost. 

6.2.4  Memory  Overhead  > 

To  make  the  System  acceptable  for  day-to-day  use  by  the  helicopter  analysis  com- 
munity, the  amount  of  computer  memory  required  by  executive  software  must  not 
contribute  significantly  to  the  total  computer  memory  required  for  an  analysis  run. 

To  minimize  the  memory  overhead  contribution  of  executive  software,  the  execu- 
tive design  approach  used  minimizes  the  amount  of  executive  software  which  must 
be  resident  in  the  computer  while  a software  element  is  executing.  Two  types  of 
executive  services  are  required  by  a software  element  during  execution:  run-time 
control  services  and  data  base  management  services. 

The  Run-Time  Control  Package  includes  three  sets  of  run-time  capabilities: 
identifying  the  input  data  in  the  Run  Data  Base  to  be  used  by  a software  element, 
intercepting  unexpected  processing  errors  occurring  during  software  element  exe- 
cution, and  detecting  normal  termination  of  software  element  execution.  The  only 

run-time  control  capabilities  which  need  be  memory  resident  while  a software  ele- 

1 

ment  is  executing  are  the  capability  to  intercept  unexpected  processing  errors 
occurring  during  software  element  execution  and  the  capability  to  detect  normal 
termination  of  software  element  execution.  These  two  run-time  control  capabil- 
ities represent  a very  small  software  subset  of  all  run-time  control  capabilities. 

Therefore,  the  memory  overhead  contribution  of  the  Run  Time  Control  Package 
is  expected  to  be  very  small  in  proportion  to  the  memory  requirements  of  an 
average  analysis  software  element. 

The  Data  Base  Management  Subsystem  includes  two  sets  of  data  base  management 
capabilities:  reading/writing  data  from/to  the  Master  Data  Base  and  reading/ 
writing  data  from/to  the  Run  Data  Base.  Because  a software  element  will  not, 
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in  CSC's  design,  directly  access  any  data  from  the  Master  Data  Base,  the  data 
base  management  software  that  manages  the  Master  Data  Base  need  not  be  memory 
resident  while  a software  element  is  executing.  In  addition,  few  technology  soft- 
ware elements  will  require  that  data  be  written  onto  non-memory-resident  portions 
of  the  Run  Data  Base,  e.g. , those  software  elements  that  will  be  generating  mat- 
rices that  exceed  the  size  of  data  memory  available  to  the  analysis  run.  For  small 
problems,  only  the  data  base  management  services  required  to  access  data  from 
the  Run  Data  Base  need  be  memory  resident  while  a software  element  is  executing. 

The  planned  partitioning  of  run-time  control  and  data  base  management  services 
into  services  required  prior  to  software  element  execution,  during  software  ele- 
ment execution,  and  after  software  element  execution  will  minimize  the  executive 
software  required  during  software  element  execution.  In  this  way,  the  CSC  de- 
sign of  the  System  executive  will  ensure  that  the  memory  overhead  of  the  System 
executive  is  minimized  and  will  not  contribute  significantly  to  the  total  computer 
memory  required  for  an  analysis  run. 
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GLOSSARY 


This  glossary  contains  terms  used  in  the  CSC/BHT  System  design.  The  glos- 
sary forms  the  basis  for,  and  will  evolve  into,  the  Project  glossary  that  will 
{ be  part  of  the  System  Development  Plan  (see  Section  5.2. 1). 

Term  Definition 
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An  aerodynamic  node  point  is 
a node  point  at  which  an  aero- 
dynamic load  is  applied,  (see 
node  point) 

Analysis  degrees  of  freedom  are 
all  of  the  independent  degrees  of 
freedom  which  are  elements  of 
the  q,  q,  or  q vectors  in  the  ma- 
trix representation  of  the  System 
equations  of  motion. 

analysis  run  An  analysis  run  is  a computer 

job  in  which  the  Operational 
Complex  of  the  System  is  exe- 
cuted. An  analysis  run  consists 
of  one  or  more  cases. 

array  An  array  is  a collection  of  named 

data  of  a single  type  identified 
and  managed  as  a single  entity 
for  convenience  and  efficiency. 

An  array  contains  data-items 
which  are  identified  by  indices 
appended  to  the  array  name; 
e.g. , B(l,3)  denotes  the  ele- 
ment of  the  first  row  and  third 
column  of  the  array  B. 

complex  The  System  is  made  up  of  two 

complexes:  the  Operational  Com- 
plex and  the  Support  Complex. 

The  Operational  Complex  is  that 
subset  of  modules  of  the  System 


aerodynamic  node  point 


analysis  degrees  of 
freedom 
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Term 


Definition 


complex  (cont'd)  used  by  the  analyst  to  obtain  pre- 

dictions In  the  following  five 
areas  of  helicopter  analysis: 
performance,  stability  and  con- 
trol, loads  and  vibrations, 
acoustics,  and  aeroelastic 
stability.  The  Support  Complex 
is  that  subset  of  modules  of  the 
System  needed  to  support  the 
development,  test,  configuration 
management,  and  documentation 
of  the  Operational  Complex  and 
to  support  the  overall  manage- 
ment of  the  System.  The  two 
complexes  are  mutually  exclusive 
and  exhaustive;  i.e. , a module 
of  the  System  is  an  element  of 
the  Operational  Complex  or  of 
the  Support  Complex  but  not  an 
element  of  both,  and  every  mod- 
ule of  the  System  is  an  element 
of  one  of  the  complexes. 

data  element  The  term  "data  element"  is  used 

to  denote,  nonspeclfically,  a 
member  of  the  data  hierarchy  in 
the  Master  Data  Base  or  Run 
Data  Base;  i.e. , a data  element 
may  be  a data -item,  an  array, 
or  a set. 

dala-ltem  A data-item  is  the  smallest  ele- 

ment of  named  data  which  is 
separately  identified  and  man- 
aged. Data-items  may  vary  in 
size  and  type. 

development  computer  A development  computer  is  a 

computer  used  by  the  Develop- 
ment Phase  Contractor  to  im- 
plement and  test  the  System. 
There  are  two  development 
computers:  one  for  the  Host  1 
computer  family,  the  other  for 
the  Host  2 computer  family. 
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dynamic  node  point 


Executive  Component 
file 


Host  1 computer  family 


Host  2 computer  family 


integral 


library 


A dynamic  node  point  is  a node 
point  at  which  motions  are  de- 
fined or  are  to  be  calculated  or 
at  which  dynamic  loads  are 
applied,  (see  node  point) 

See  subsystem. 

A file  is  a collection  of  data 
residing  on  an  external  storage 
device;  a file  has  no  implica- 
tion of  a data  hierarchy  asso- 
ciated with  it. 

The  Host  1 computer  family 
consists  of  the  IBM  S/370 
Model  158  trader  OS/VS,  the 
IBM  S/370  Model  168  under 
OS/VS,  and  the  IBM  S/360 
Model  65  under  OS/MVT. 

The  Host  2 computer  family 
consists  of  the  CDC  6000 
series  under  NOS  and  the 
CDC  CYBER  series  under  NOS. 

A software  element  Is  said  to  be 
Integral  if  it  contains  a unique 
module,  called  the  control  mod- 
ule, which  controls  the  Invocation 
of  other  modules  in  the  software 
element  and  in  other  software 
elements  such  that  the  entire 
capability  of  the  software  ele- 
ment may  be  accessed  by  Invo- 
cation of  the  control  module. 

A library  Is  a collection  of  soft- 
ware (e.g. , source  modules, 
macros,  object  modules)  resid- 
ing on  an  external  storage  device. 
A library  has  no  Implication  of 
a software  hierarchy  associated 
with  it. 
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Term 


load-module 


Master  Data 


module 


node  point 


Base 


Definition 


A load-module  is  a discrete  and 
identifiable  software  unit  which 
is  output  by  a link  editor  in  a 
form  which  can  be  loaded  into 
memory  and  executed  directly. 

A load-module  contains  one  or 
more  modules. 

The  Master  Data  Base  is  a col- 
lection of  data  at  each  installa- 
tion which  describes  aircraft, 
aircraft  components,  and  other 
analysis  components  which  may 
be  analyzed;  maneuvers,  condi- 
tions, and  operating  regimes  for 
an  analysis;  and  failure/damage 
effects  which  might  be  considered. 
It  is  the  intent  of  the  System  de- 
sign that  data  which  is  used  re- 
peatedly in  analysis  at  an 
installation  will  be  maintained 
in  the  Master  Data  Base  by 
authorized  personnel  at  the  in- 
stallation. 

A module  has  the  following 
principal  characteristics:  (1)  It 
performs  only  one  function; 

(2)  it  has  a unique  name;  (3)  it 
constitutes  one  compilation  or 
assembly;  (4)  it  has  only  one 
point  of  entry.  An  invocable, 
executable  module  consists  of 
no  more  than  100  executable 
source  language  statements. 

(Note  that  not  all  modules  are 
executable;  e.g. , a FORTRAN 
block  data  subprogram  is  an  ex- 
ample of  a nonexecutable  module. ) 

A node  point  Is  a distinct  loca- 
tion, which  is  part  of  the  con- 
figuration, at  which  motions  or 
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node  point  (cont’d)  loads  are  specified  or  desired. 

Node  points  are  divided  into 
two  types:  dynamic  node  points 
and  aerodynamic  node  points. 

A node  point  may  be  both  an 
aerodynamic  node  point  and  a 
dynamic  node  point. 

Operational  Complex  See  complex. 


package 


Run  Data  Base 


Each  subsystem  is  made  up  of 
packages.  A package  is  a set 
of  modules  that  together  per- 
forms a related  aggregate  of 
functions  of  the  subsystem  to 
which  it  belongs.  Every  mod- 
ule of  the  System  belongs  to  one 
and  only  one  package.  (Large 
packages  are  frequently  com- 
posed of  subpackage b;  subpack- 
age is  defined  below. ) Execution 
of  the  packages  and  subpackages 
of  the  Technology  Component  is 
controlled  by  the  Executive  Com- 
ponent. Packages  and  subpack- 
ages may  be  invoked  either  as  a 
result  of  entries  in  the  Sequence 
Control  Table,  which  is  con- 
structed from  user-specified 
data  by  the  Executive  Component 
during  the  input  phase  of  an 
analysis  run,  or  as  a result  of 
requests  from  a module  of  the 
Technology  Component  during 
the  Processing  Phase  of  an 
analysis  run. 

The  Run  Data  Base  is  a collec- 
tion of  data  which  describes  the 
following  for  an  analysis  run: 
the  aircraft,  aircraft  components, 
and  other  analysis  components  to 
be  analyzed;  maneuvers,  condi- 
tions, and  operating  regimes  for 
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Run  Data  Base  (cont'd) 

the  analysis;  failure/damage 
effects  to  be  applied  during  the 
analysis  run;  temporary  values 
calculated  during  the  anal  -sis 
run  for  use  later  in  the  analysis 

♦ 

i l 

i 

f 

run;  and  output  values  calculated 
during  the  analysis  run.  The 

Run  Data  Base  is  created  for  an 

analysis  run  and  is  destroyed  at 
the  end  of  the  analysis  run. 

A 

separable 

A software  element  is  said  to 
be  separable  if  it  does  not  con- 
tain a unique  module,  called 
the  control  module,  through 
which  the  entire  capability  of 
the  software  element  can  be 
accessed. 

i 

Sequence  Control  Table 

The  Sequence  Control  Table  is 
a System  Command  Sequence 
in  internal  computer  form. 

set 

A set  (of  data)  is  a collection 
of  related  data  in  a data  base 
identified  and  managed  as  a 
single  entity  for  convenience 
and  efficiency.  The  Master 

Data  Base  and  the  Run  Data 

Base  contain  sets.  A set  may 
contain  other  sets,  arrays,  and 

• 

i 

r 
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data-items. 
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software  element 

The  term  "software  element"  is 
used  to  denote,  nonspecifically, 
a member  of  the  System  software 
hierarchy.  The  term  is  usually 

r 

! 

| 

used  to  denote  either  a package 
or  a subpackage. 

* 

subpackage 

Each  package  may  be  made  up  of 
subpackages.  A subpackage  is  a 
set  of  modules  that  together 

1 [ 
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subsequence 
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performs  a related  aggregate  of 

functions  of  the  package  to  which  i 

it  belongs. 

See  System  Command  Sub- 
sequence. 

A subsequence  set  is  a collection 
of  System  Command  Subsequences 
all  of  which  perform  the  same 
major  System  function  but  which 
differ  from  each  other  in  either 
the  methods  used  to  perform  the 
common  function  or  the  level  of 
detail  at  which  the  common  func- 
tion is  analyzed. 

Each  complex  is  made  up  of  sub- 
systems. A subsystem  is  a set 
of  modules  that  performs  a 
related  aggregate  of  System  func- 
tions. A subsystem  is  not  an 
executable  entity.  Subsystems 
are  defined  to  relate  the  software 
design  of  the  System  to  the  re- 
quirements of  the  Type  A System 
Specification;  to  aid  in  presenting 
a logical,  top-down  design;  and  to 
aid  in  configuration  management. 

Every  module  of  the  System 
belongs  to  one  and  only  one  sub- 
system. In  the  Operational 
Complex,  a subsystem  is  char- 
acterized as  being  an  executive 
subsystem  or  a technology 
subsystem.  The  collection  of  ex- 
cutive  subsystems  is  called  the 
Executive  Component,  and  the 
collection  of  technology  sub- 
systems is  called  the  Technology 
Component.  The  Executive  Com- 
ponent provides  the  ftinctions  of 
user  interface,  run-time  man- 
agement, data  base  management, 
and  operating  system  interface. 
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The  Technology  Component  pro- 
vides all  the  functions  of  heli- 
copter and  associated  mathematical 
analyses.  These  two  components 
are  mutually  exclusive  and  exhaus- 
tive; i.e. , a module  in  the  Opera- 
tional Complex  is  in  one  and  only  f 

one  component. 

See  complex. 

The  word  System  (note  the  ^ 

upper  case  S)  is  a shorthand 
equivalent  for  the  Second  Gen- 
eration Comprehensive  Heli- 
copter Analysis  System.  The 
System,  which  is  a software 
system,  is  to  be  developed  by 
the  Government  to  accurately 
predict  performance,  stability 
and  control,  loads  and  vibra- 
tions, acoustics,  and  aeroelas- 
tic  stability  for  a variety  of 
rotary-wing  aircraft  configura- 
tions. The  System  is  made  up 
of  a set  (collection)  of  modules. 

Because  a module  is  a relatively 
small  part  of  the  System  (a  mod- 
ule consists  of  no  more  than 
100  executable  source  language 
statements),  names  are  given  to 
particular  sets  of  modules  in  the 
System.  The  names  used  to  de- 
scribe the  System's  hierarchy  are 
complex,  subsystem,  package, 
and  subpackage.  These  sets  of  ‘ 

modules  are,  in  the  terminology 
of  set  theory,  subsets  of  the  Sys- 
tem. The  System  is  composed  of 
two  complexes;  a complex  in  turn  J 

is  composed  of  subsystems;  a sub- 
system is  composed  of  packages;  a 
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package  may  be  composed  of  sub- 
packages; and,  finally,  subpack- 
ages are  composed  of  either  other 
subpackages  or  modules.  Every 
member  of  this  hierarchy  (com- 
plex, subsystem,  package,  sub- 
package) can  be  thought  of  as 
being  composed  of  modules. 

A System  Command  Sequence  is 
a set  of  System  Commands  which 
specify  the  actions  to  be  taken  by 
the  System  to  perform  an  analy- 
sis. A Particular  Functional 
Capability  is  represented  by  a 
System  Command  Sequence. 

A System  Command  Subsequence 
is  a set  of  System  Commands 
which  perform  a single  major 
System  function.  System  Com- 
mand Subsequences  may  be 
combined  to  form  System  Com- 
mand Sequences. 

target  computer  A target  computer  is  a computer 

at  a user's  installation  on  which 
the  System  will  be  installed. 

Technology  Component  See  subsystem. 
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System  Command  Sub- 
sequence 


